Skip to main content

Browse the archive

https://github.com/postgres/postgres
07 April 2024, 13:56:23 UTC
sort by:
Revision Author Date Message Commit Date
d06fe6c Tom Lane 06 November 2018, 23:56:26 UTC Last-minute updates for release notes. Add entries for v11 changes that went in post-stamping, but before the final wrap. 06 November 2018, 23:56:26 UTC
05f8460 Tom Lane 06 November 2018, 23:33:15 UTC Disable recheck_on_update optimization to avoid crashes. The code added by commit c203d6cf8 causes a crash in at least one case, where a potentially-optimizable expression index has a storage type different from the input data type. A cursory code review turned up numerous other problems that seem impractical to fix on short notice. Andres argued for revert of that patch some time ago, and if additional senior committers had been paying attention, that's likely what would have happened, but we were not :-( At this point we can't just revert, at least not in v11, because that would mean an ABI break for code touching relcache entries. And we should not remove the (also buggy) support for the recheck_on_update index reloption, since it might already be used in some databases in the field. So this patch just does the as-little-invasive-as-possible measure of disabling the feature as though recheck_on_update were forced off for all indexes. I also removed the related regression tests (which would otherwise fail) and the user-facing documentation of the reloption. We should undertake a more thorough code cleanup if the patch can't be fixed, but not under the extreme time pressure of being already overdue for 11.1 release. Per report from Ondřej Bouda and subsequent private discussion among pgsql-release. Discussion: https://postgr.es/m/20181106185255.776mstcyehnc63ty@alvherre.pgsql 06 November 2018, 23:33:33 UTC
1833d23 Bruce Momjian 06 November 2018, 18:40:02 UTC GUC: adjust effective_cache_size SQL descriptions Follow on patch for commit 3e0f1a4741f564c1a2fa6e944729d6967355d8c7. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/369ec766-b947-51bd-4dad-6fb9e026439f@2ndquadrant.com Backpatch-through: 9.4 06 November 2018, 18:40:02 UTC
1f28ec6 Tom Lane 06 November 2018, 18:25:24 UTC Rename rbtree.c functions to use "rbt" prefix not "rb" prefix. The "rb" prefix is used by Ruby, so that our existing code results in name collisions that break plruby. We discussed ways to prevent that by adjusting dynamic linker options, but it seems that at best we'd move the pain to other cases. Renaming to avoid the collision is the only portable fix anyway. Fortunately, our rbtree code is not (yet?) widely used --- in core, there's only a single usage in GIN --- so it seems likely that we can get away with a rename. I chose to do this basically as s/rb/rbt/g, except for places where there already was a "t" after "rb". The patch could have been made smaller by only touching linker-visible symbols, but it would have resulted in oddly inconsistent-looking code. Better to make it look like "rbt" was the plan all along. Back-patch to v10. The rbtree.c code exists back to 9.5, but rb_iterate() which is the actual immediate source of pain was added in v10, so it seems like changing the names before that would have more risk than benefit. Per report from Pavel Raiskup. Discussion: https://postgr.es/m/4738198.8KVIIDhgEB@nb.usersys.redhat.com 06 November 2018, 18:25:24 UTC
fef63a8 Tom Lane 05 November 2018, 21:43:09 UTC Stamp 11.1. 05 November 2018, 21:43:09 UTC
1623740 Tom Lane 05 November 2018, 21:07:06 UTC Last-minute updates for release notes. I removed the item about the pg_stat_statements change from release-11.sgml, as part of a sweep to delete items already committed in 11.0; but actually we'd best keep it to ensure that people who've pg_upgraded their databases will take the requisite action. Also make said action more visible by making it into its own para. Noted by Jonathan Katz. 05 November 2018, 21:07:06 UTC
9c7049e Andres Freund 05 November 2018, 20:02:25 UTC Fix copy-paste error in errhint() introduced in 691d79a07933. Reported-By: Petr Jelinek Discussion: https://postgr.es/m/c95a620b-34f0-7930-aeb5-f7ab804f26cb@2ndquadrant.com Backpatch: 9.4-, like the previous commit 05 November 2018, 20:05:39 UTC
2da33cb Tom Lane 05 November 2018, 15:48:23 UTC Last-minute updates for release notes. Security: CVE-2018-16850 05 November 2018, 15:48:23 UTC
af5ab11 Peter Eisentraut 05 November 2018, 13:43:50 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 707f81a8bc147ef576cbddd13069c7ae97c76307 05 November 2018, 13:43:50 UTC
7c222d5 Michael Paquier 05 November 2018, 02:04:14 UTC Block creation of partitions with open references to its parent When a partition is created as part of a trigger processing, it is possible that the partition which just gets created changes the properties of the table the executor of the ongoing command relies on, causing a subsequent crash. This has been found possible when for example using a BEFORE INSERT which creates a new partition for a partitioned table being inserted to. Any attempt to do so is blocked when working on a partition, with regression tests added for both CREATE TABLE PARTITION OF and ALTER TABLE ATTACH PARTITION. Reported-by: Dmitry Shalashov Author: Amit Langote Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/15437-3fe01ee66bd1bae1@postgresql.org Backpatch-through: 10 05 November 2018, 02:04:14 UTC
948af52 Michael Paquier 05 November 2018, 00:15:08 UTC Ignore partitioned tables when processing ON COMMIT DELETE ROWS Those tables have no physical storage, making this option unusable with partition trees as at commit time an actual truncation was attempted. There are still issues with the way ON COMMIT actions are done when mixing several action types, however this impacts as well inheritance trees, so this issue will be dealt with later. Reported-by: Rajkumar Raghuwanshi Author: Amit Langote Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/CAKcux6mhgcjSiB_egqEAEFgX462QZtncU8QCAJ2HZwM-wWGVew@mail.gmail.com 05 November 2018, 00:15:08 UTC
84010b9 Tom Lane 04 November 2018, 21:57:14 UTC Release notes for 11.1, 10.6, 9.6.11, 9.5.15, 9.4.20, 9.3.25. 04 November 2018, 21:57:14 UTC
d358da8 Tom Lane 04 November 2018, 19:50:55 UTC Fix ExecuteCallStmt to not scribble on the passed-in parse tree. Modifying the parse tree at execution time is, or at least ought to be, verboten. It seems quite difficult to actually cause a crash this way in v11 (although you can exhibit it pretty easily in HEAD by messing with plan_cache_mode). Nonetheless, it's risky, so fix and back-patch. Discussion: https://postgr.es/m/13789.1541359611@sss.pgh.pa.us 04 November 2018, 19:50:55 UTC
4b0c371 Tom Lane 04 November 2018, 18:25:39 UTC Fix bugs in plpgsql's handling of CALL argument lists. exec_stmt_call() tried to extract information out of a CALL statement's argument list without using expand_function_arguments(), apparently in the hope of saving a few nanoseconds by not processing defaulted arguments. It got that quite wrong though, leading to crashes with named arguments, as well as failure to enforce writability of the argument for a defaulted INOUT parameter. Fix and simplify the logic by using expand_function_arguments() before examining the list. Also, move the argument-examination to just after producing the CALL command's plan, before invoking the called procedure. This ensures that we'll track possible changes in the procedure's argument list correctly, and avoids a hazard of the plan cache being flushed while the procedure executes. Also fix assorted falsehoods and omissions in associated documentation. Per bug #15477 from Alexey Stepanov. Patch by me, with some help from Pavel Stehule. Back-patch to v11. Discussion: https://postgr.es/m/15477-86075b1d1d319e0a@postgresql.org Discussion: https://postgr.es/m/CAFj8pRA6UsujpTs9Sdwmk-R6yQykPx46wgjj+YZ7zxm4onrDyw@mail.gmail.com 04 November 2018, 18:25:39 UTC
6f4e01c Tom Lane 04 November 2018, 16:20:59 UTC Fix unused-variable warning. Discussion: https://postgr.es/m/CAMkU=1xTHkS6d0iptCWykHc1Xrh3LBic_gZDo3JzDYru815fLQ@mail.gmail.com 04 November 2018, 16:21:11 UTC
6eb31ce Andres Freund 03 November 2018, 22:55:23 UTC Prevent generating EEOP_AGG_STRICT_INPUT_CHECK operations when nargs == 0. This only became a problem with 4c640f4f38, which didn't synchronize the value agg_strict_input_check.nargs is set to, with the guard condition for emitting the operation. Besides such instructions being unnecessary overhead, currently the LLVM JIT provider doesn't support them. It seems more sensible to avoid generating such instruction than supporting them. Add assertions to make it easier to debug a potential further occurance. Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108ac52@email.cz Backpatch: 11-, like 4c640f4f38. 03 November 2018, 23:00:00 UTC
fd59b29 Andres Freund 03 November 2018, 21:35:23 UTC Fix STRICT check for strict aggregates with NULL ORDER BY columns. I (Andres) broke this unintentionally in 69c3936a14, by checking strictness for all input expressions computed for an aggregate, rather than just the input for the aggregate transition function. Reported-By: Ondřej Bouda Bisected-By: Tom Lane Diagnosed-By: Andrew Gierth Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108ac52@email.cz Backpatch: 11-, like 69c3936a14 03 November 2018, 21:48:42 UTC
bf4a956 Tom Lane 03 November 2018, 17:56:10 UTC Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+FFFF will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f114@postgresql.org 03 November 2018, 17:56:10 UTC
33e6c34 Alvaro Herrera 03 November 2018, 16:23:37 UTC Fix tablespace handling for partitioned indexes When creating partitioned indexes, the tablespace was not being saved for the parent index. This meant that subsequently created partitions would not use the right tablespace for their indexes. ALTER INDEX SET TABLESPACE and ALTER INDEX ALL IN TABLESPACE raised errors when tried; fix them too. This requires bespoke code for ATExecCmd() that applies to the special case when the tablespace move is just a catalog change. Discussion: https://postgr.es/m/20181102003138.uxpaca6qfxzskepi@alvherre.pgsql 03 November 2018, 16:25:29 UTC
0e88ba1 Stephen Frost 03 November 2018, 16:22:01 UTC Remove extra word from create sub docs Improve the documentation in the CREATE SUBSCRIPTION command a bit by removing an extraneous word and spelling out 'information'. 03 November 2018, 16:22:01 UTC
df1d749 Tom Lane 02 November 2018, 22:54:00 UTC Yet further rethinking of build changes for macOS Mojave. The solution arrived at in commit e74dd00f5 presumes that the compiler has a suitable default -isysroot setting ... but further experience shows that in many combinations of macOS version, XCode version, Xcode command line tools version, and phase of the moon, Apple's compiler will *not* supply a default -isysroot value. We could potentially go back to the approach used in commit 68fc227dd, but I don't have a lot of faith in the reliability or life expectancy of that either. Let's just revert to the approach already shipped in 11.0, namely specifying an -isysroot switch globally. As a partial response to the concerns raised by Jakob Egger, adjust the contents of Makefile.global to look like CPPFLAGS = -isysroot $(PG_SYSROOT) ... PG_SYSROOT = /path/to/sysroot This allows overriding the sysroot path at build time in a relatively painless way. Add documentation to installation.sgml about how to use the PG_SYSROOT option. I also took the opportunity to document how to work around macOS's "System Integrity Protection" feature. As before, back-patch to all supported versions. Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us 02 November 2018, 22:54:00 UTC
fd6449a Thomas Munro 02 November 2018, 22:08:03 UTC Fix NULL handling in multi-batch Parallel Hash Left Join. NULL keys in left joins were skipped when building batch files. Repair, by making the keep_nulls argument to ExecHashGetHashValue() depend on whether this is a left outer join, as we do in other paths. Bug #15475. Thinko in 1804284042e. Back-patch to 11. Reported-by: Paul Schaap Diagnosed-by: Andrew Gierth Dicussion: https://postgr.es/m/15475-11a7a783fed72a36%40postgresql.org 02 November 2018, 22:08:03 UTC
ca49b5c Bruce Momjian 02 November 2018, 17:05:30 UTC docs: adjust simpler language for NULL return from ANY/ALL Adjustment to commit 8610c973ddf1cbf0befc1369d2cf0d56c0efcd0a. Reported-by: Tom Lane Discussion: https://postgr.es/m/17406.1541168421@sss.pgh.pa.us Backpatch-through: 9.3 02 November 2018, 17:05:30 UTC
2352441 Bruce Momjian 02 November 2018, 13:11:00 UTC GUC: adjust effective_cache_size docs and SQL description Clarify that effective_cache_size is both kernel buffers and shared buffers. Reported-by: nat@makarevitch.org Discussion: https://postgr.es/m/153685164808.22334.15432535018443165207@wrigleys.postgresql.org Backpatch-through: 9.3 02 November 2018, 13:11:00 UTC
708b96d Magnus Hagander 02 November 2018, 12:55:57 UTC Fix some spelling errors in the documentation Author: Daniel Gustafsson <daniel@yesql.se> 02 November 2018, 12:57:10 UTC
61abff1 Bruce Momjian 02 November 2018, 12:54:34 UTC doc: use simpler language for NULL return from ANY/ALL Previously the combination of "does not return" and "any row" caused ambiguity. Reported-by: KES <kes-kes@yandex.ru> Discussion: https://postgr.es/m/153701242703.22334.1476830122267077397@wrigleys.postgresql.org Reviewed-by: David G. Johnston Backpatch-through: 9.3 02 November 2018, 12:54:34 UTC
0446551 Andres Freund 01 November 2018, 17:44:29 UTC Fix error message typo introduced 691d79a07933. Reported-By: Michael Paquier Discussion: https://postgr.es/m/20181101003405.GB1727@paquier.xyz Backpatch: 9.4-, like the previous commit 01 November 2018, 17:44:53 UTC
886319d Peter Geoghegan 01 November 2018, 16:18:55 UTC Adjust trace_sort log messages. The project message style guide dictates: "When citing the name of an object, state what kind of object it is". The parallel CREATE INDEX patch added a worker number to most of the trace_sort messages within tuplesort.c without specifying the object type. Bring these messages into compliance with the style guide. We're still treating a leader or serial Tuplesortstate as having worker number -1. trace_sort is a developer option, and these two cases are highly comparable, so this seems appropriate. Per complaint from Tom Lane. Discussion: https://postgr.es/m/8330.1540831863@sss.pgh.pa.us Backpatch: 11-, where parallel CREATE INDEX was introduced. 01 November 2018, 16:18:55 UTC
c33a01c Andres Freund 31 October 2018, 21:47:41 UTC Disallow starting server with insufficient wal_level for existing slot. Previously it was possible to create a slot, change wal_level, and restart, even if the new wal_level was insufficient for the slot. That's a problem for both logical and physical slots, because the necessary WAL records are not generated. This removes a few tests in newer versions that, somewhat inexplicably, whether restarting with a too low wal_level worked (a buggy behaviour!). Reported-By: Joshua D. Drake Author: Andres Freund Discussion: https://postgr.es/m/20181029191304.lbsmhshkyymhw22w@alap3.anarazel.de Backpatch: 9.4-, where replication slots where introduced 31 October 2018, 22:46:40 UTC
2493e2c Tom Lane 31 October 2018, 21:04:42 UTC Fix memory leak in repeated SPGIST index scans. spgendscan neglected to pfree all the memory allocated by spgbeginscan. It's possible to get away with that in most normal queries, since the memory is allocated in the executor's per-query context which is about to get deleted anyway; but it causes severe memory leakage during creation or filling of large exclusion-constraint indexes. Also, document that amendscan is supposed to free what ambeginscan allocates. The docs' lack of clarity on that point probably caused this bug to begin with. (There is discussion of changing that API spec going forward, but I don't think it'd be appropriate for the back branches.) Per report from Bruno Wolff. It's been like this since the beginning, so back-patch to all active branches. In HEAD, also fix an independent leak caused by commit 2a6368343 (allocating memory during spgrescan instead of spgbeginscan, which might be all right if it got cleaned up, but it didn't). And do a bit of code beautification on that commit, too. Discussion: https://postgr.es/m/20181024012314.GA27428@wolff.to 31 October 2018, 21:04:42 UTC
f107c33 Tom Lane 31 October 2018, 13:47:53 UTC Sync our copy of the timezone library with IANA release tzcode2018g. This patch absorbs an upstream fix to "zic" for a recently-introduced bug that made it output data that some 32-bit clients couldn't read. Given the current source data, the bug only manifests in zones with leap seconds, which we don't generate, so that there's no actual change in our installed timezone data files from this. Still, in case somebody uses our copy of "zic" to do something else, it seems best to apply the fix promptly. Also, update the README's notes about converting upstream code to our conventions. 31 October 2018, 13:48:04 UTC
58c45fd Tom Lane 31 October 2018, 12:35:50 UTC Update time zone data files to tzdata release 2018g. DST law changes in Morocco (with, effectively, zero notice). Historical corrections for Hawaii. 31 October 2018, 12:36:06 UTC
2bd6dcd Tom Lane 30 October 2018, 19:26:11 UTC Fix interaction of CASE and ArrayCoerceExpr. An array-type coercion appearing within a CASE that has a constant (after const-folding) test expression was mangled by the planner, causing all the elements of the resulting array to be equal to the coerced value of the CASE's test expression. This is my oversight in commit c12d570fa: that changed ArrayCoerceExpr to use a subexpression involving a CaseTestExpr, and I didn't notice that eval_const_expressions needed an adjustment to keep from folding such a CaseTestExpr to a constant when it's inside a suitable CASE. This is another in what's getting to be a depressingly long line of bugs associated with misidentification of the referent of a CaseTestExpr. We're overdue to redesign that mechanism; but any such fix is unlikely to be back-patchable into v11. As a stopgap, fix eval_const_expressions to do what it must here. Also add a bunch of comments pointing out the restrictions and assumptions that are needed to make this work at all. Also fix a related oversight: contain_context_dependent_node() was not aware of the relationship of ArrayCoerceExpr to CaseTestExpr. That was somewhat fail-soft, in that the outcome of a wrong answer would be to prevent optimizations that could have been made, but let's fix it while we're at it. Per bug #15471 from Matt Williams. Back-patch to v11 where the faulty logic came in. Discussion: https://postgr.es/m/15471-1117f49271989bad@postgresql.org 30 October 2018, 19:26:11 UTC
b5f1717 Magnus Hagander 29 October 2018, 11:34:49 UTC Fix missing whitespace in pg_dump ref page Author: Daniel Gustafsson <daniel@yesql.se> 29 October 2018, 11:35:50 UTC
29cdf02 Peter Eisentraut 29 October 2018, 10:31:43 UTC pg_restore: Augment documentation for -N option This was forgotten when the option was added. Author: Michael Banck <michael.banck@credativ.de> 29 October 2018, 10:32:27 UTC
c653cb2 Thomas Munro 28 October 2018, 23:57:55 UTC Remove incorrect comment in dshash.c. Back-patch to 11. Author: Antonin Houska Discussion: https://postgr.es/m/8726.1540553521%40localhost 29 October 2018, 00:00:11 UTC
8cb5e67 Andrew Dunstan 28 October 2018, 16:22:32 UTC Fix perl searchpath for modern perl for MSVC tools Modern versions of perl no longer include the current directory in the perl searchpath, as it's insecure. Instead of adding the current directory, we get around the problem by adding the directory where the script lives. Problem noted by Victor Wagner. Solution adapted from buildfarm client code. Backpatch to all live versions. 28 October 2018, 16:23:19 UTC
fdf5ead Michael Paquier 26 October 2018, 14:36:40 UTC Add tab completion of EXECUTE FUNCTION for CREATE TRIGGER in psql The change to accept EXECUTE FUNCTION as well as EXECUTE PROCEDURE in CREATE TRIGGER (added by 0a63f99) forgot to tell psql's tab completion system about this. This change is version-aware, with FUNCTION being selected automatically instead of PROCEDURE depending on the backend version, PROCEDURE being an historical grammar kept for compatibility and considered as deprecated in v11. Author: Dagfinn Ilmari Mannsåker Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/d8jmur4q4yc.fsf@dalvik.ping.uio.no 26 October 2018, 14:36:40 UTC
ef45832 Andrew Dunstan 24 October 2018, 23:39:50 UTC Fix typo in regression test comment per Michael Banck 24 October 2018, 23:40:58 UTC
372102b Andrew Dunstan 24 October 2018, 14:45:34 UTC Correctly set t_self for heap tuples in expand_tuple Commit 16828d5c0 incorrectly set an invalid pointer for t_self for heap tuples. This patch correctly copies it from the source tuple, and includes a regression test that relies on it being set correctly. Backpatch to release 11. Fixes bug #15448 reported by Tillmann Schulz Diagnosis and test case by Amit Langote 24 October 2018, 14:57:35 UTC
374fe86 Michael Paquier 24 October 2018, 08:02:45 UTC List wait events in alphabetical order in documentation Keeping all those entries in order helps the user looking at the documentation in finding them. Author: Michael Paquier, Kuntal Ghosh Discussion: https://postgr.es/m/20181024002539.GI1658@paquier.xy 24 October 2018, 08:02:45 UTC
d5845b2 Michael Paquier 22 October 2018, 06:39:32 UTC Fix description of pg_class.relispartition in documentation This missed the fact that indexes can be partitions since 11. Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20181022031212.GF14282@paquier.xyz 22 October 2018, 06:39:32 UTC
33df118 Alexander Korotkov 21 October 2018, 21:23:26 UTC Fix some grammar errors in bloom.sgml Discussion: https://postgr.es/m/CAEepm%3D3sijpGr8tXdyz-7EJJZfhQHABPKEQ29gpnb7-XSy%2B%3D5A%40mail.gmail.com Reported-by: Thomas Munro Backpatch-through: 9.6 21 October 2018, 21:29:03 UTC
a0a8671 Andrew Dunstan 20 October 2018, 13:02:36 UTC Lower privilege level of programs calling regression_main On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth the trouble. Discussion: https://postgr.es/m/650b0c29-9578-8571-b1d2-550d7f89f307@2ndQuadrant.com 20 October 2018, 13:10:02 UTC
d30d27a Tom Lane 20 October 2018, 02:22:57 UTC Client-side fixes for delayed NOTIFY receipt. PQnotifies() is defined to just process already-read data, not try to read any more from the socket. (This is a debatable decision, perhaps, but I'm hesitant to change longstanding library behavior.) The documentation has long recommended calling PQconsumeInput() before PQnotifies() to ensure that any already-arrived message would get absorbed and processed. However, psql did not get that memo, which explains why it's not very reliable about reporting notifications promptly. Also, most (not quite all) callers called PQconsumeInput() just once before a PQnotifies() loop. Taking this recommendation seriously implies that we should do PQconsumeInput() before each call. This is more important now that we have "payload" strings in notification messages than it was before; that increases the probability of having more than one packet's worth of notify messages. Hence, adjust code as well as documentation examples to do it like that. Back-patch to 9.5 to match related server fixes. In principle we could probably go back further with these changes, but given lack of field complaints I doubt it's worthwhile. Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com 20 October 2018, 02:22:57 UTC
7aaeb7b Tom Lane 20 October 2018, 01:39:21 UTC Server-side fix for delayed NOTIFY and SIGTERM processing. Commit 4f85fde8e introduced some code that was meant to ensure that we'd process cancel, die, sinval catchup, and notify interrupts while waiting for client input. But there was a flaw: it supposed that the process latch would be set upon arrival at secure_read() if any such interrupt was pending. In reality, we might well have cleared the process latch at some earlier point while those flags remained set -- particularly notifyInterruptPending, which can't be handled as long as we're within a transaction. To fix the NOTIFY case, also attempt to process signals (except ProcDiePending) before trying to read. Also, if we see that ProcDiePending is set before we read, forcibly set the process latch to ensure that we will handle that signal promptly if no data is available. I also made it set the process latch on the way out, in case there is similar logic elsewhere. (It remains true that we won't service ProcDiePending here unless we need to wait for input.) The code for handling ProcDiePending during a write needs those changes, too. Also be a little more careful about when to reset whereToSendOutput, and improve related comments. Back-patch to 9.5 where this code was added. I'm not entirely convinced that older branches don't have similar issues, but the complaint at hand is just about the >= 9.5 code. Jeff Janes and Tom Lane Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com 20 October 2018, 01:39:21 UTC
9892c18 Tom Lane 19 October 2018, 23:36:34 UTC Sync our copy of the timezone library with IANA release tzcode2018f. About half of this is purely cosmetic changes to reduce the diff between our code and theirs, like inserting "const" markers where they have them. The other half is tracking actual code changes in zic.c and localtime.c. I don't think any of these represent near-term compatibility hazards, but it seems best to stay up to date. I also fixed longstanding bugs in our code for producing the known_abbrevs.txt list, which by chance hadn't been exposed before, but which resulted in some garbage output after applying the upstream changes in zic.c. Notably, because upstream removed their old phony transitions at the Big Bang, it's now necessary to cope with TZif files containing no DST transition times at all. 19 October 2018, 23:36:34 UTC
d2259c2 Tom Lane 19 October 2018, 21:01:34 UTC Update time zone data files to tzdata release 2018f. DST law changes in Chile, Fiji, and Russia (Volgograd). Historical corrections for China, Japan, Macau, and North Korea. Note: like the previous tzdata update, this involves a depressingly large amount of semantically-meaningless churn in tzdata.zi. That is a consequence of upstream's data compression method assigning unstable abbreviations to DST rulesets. I complained about that to them last time, and this version now uses an assignment method that pays some heed to not changing abbreviations unnecessarily. So hopefully, that'll be better going forward. 19 October 2018, 21:01:49 UTC
cc7f27e Michael Paquier 19 October 2018, 13:44:12 UTC Use whitelist to choose files scanned with pg_verify_checksums The original implementation of pg_verify_checksums used a blacklist to decide which files should be skipped for scanning as they do not include data checksums, like pg_internal.init or pg_control. However, this missed two things: - Some files are created within builds of EXEC_BACKEND and these were not listed, causing failures on Windows. - Extensions may create custom files in data folders, causing the tool to equally fail. This commit switches to a whitelist-like method instead by checking if the files to scan are authorized relation files. This is close to a reverse-engineering of what is defined in relpath.c in charge of building the relation paths, and we could consider refactoring what this patch does so as all routines are in a single place. This is left for later. This is based on a suggestion from Andres Freund. TAP tests are updated so as multiple file patterns are tested. The bug has been spotted by various buildfarm members as a result of b34e84f which has introduced the TAP tests of pg_verify_checksums. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Michael Banck Discussion: https://postgr.es/m/20181012005614.GC26424@paquier.xyz Backpatch-through: 11 19 October 2018, 13:45:07 UTC
06292bb Tom Lane 19 October 2018, 04:50:16 UTC Add missing quote_identifier calls for CREATE TRIGGER ... REFERENCING. Mixed-case names for transition tables weren't dumped correctly. Oversight in commit 8c48375e5, per bug #15440 from Karl Czajkowski. In passing, I couldn't resist a bit of code beautification. Back-patch to v10 where this was introduced. Discussion: https://postgr.es/m/15440-02d1468e94d63d76@postgresql.org 19 October 2018, 04:50:16 UTC
d1e869d Tom Lane 18 October 2018, 18:55:23 UTC Still further rethinking of build changes for macOS Mojave. To avoid the sorts of problems complained of by Jakob Egger, it'd be best if configure didn't emit any references to the sysroot path at all. In the case of PL/Tcl, we can do that just by keeping our hands off the TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to substitute -iwithsysroot for -I in the compile commands, which is easily handled if we change to using a configure output variable that includes the switch not only the directory name. Since PL/Tcl and PL/Python already do it like that, this seems like good consistency cleanup anyway. Hence, this replaces the advice given to Perl-related extensions in commit 5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should just write "$(perl_includespec)". (The old way continues to work, but not on recent macOS.) It's still the case that configure needs to be aware of the sysroot path internally, but that's cleaner than what we had before. As before, back-patch to all supported versions. Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us 18 October 2018, 18:55:23 UTC
0a21c6d Tom Lane 17 October 2018, 19:06:38 UTC Fix minor bug in isolationtester. If the lock wait query failed, isolationtester would report the PQerrorMessage from some other connection, meaning there would be no message or an unrelated one. This seems like a pretty unlikely occurrence, but if it did happen, this bug could make it really difficult/confusing to figure out what happened. That seems to justify patching all the way back. In passing, clean up another place where the "wrong" conn was used for an error report. That one's not actually buggy because it's a different alias for the same connection, but it's still confusing to the reader. 17 October 2018, 19:06:38 UTC
db4f9c0 Tom Lane 17 October 2018, 16:26:48 UTC Improve tzparse's handling of TZDEFRULES ("posixrules") zone data. In the IANA timezone code, tzparse() always tries to load the zone file named by TZDEFRULES ("posixrules"). Previously, we'd hacked that logic to skip the load in the "lastditch" code path, which we use only to initialize the default "GMT" zone during GUC initialization. That's critical for a couple of reasons: since we do not support leap seconds, we *must not* allow "GMT" to have leap seconds, and since this case runs before the GUC subsystem is fully alive, we'd really rather not take the risk of pg_open_tzfile throwing any errors. However, that still left the code reading TZDEFRULES on every other call, something we'd noticed to the extent of having added code to cache the result so it was only done once per process not a lot of times. Andres Freund complained about the static data space used up for the cache; but as long as the logic was like this, there was no point in trying to get rid of that space. We can improve matters by looking a bit more closely at what the IANA code actually needs the TZDEFRULES data for. One thing it does is that if "posixrules" is a leap-second-aware zone, the leap-second behavior will be absorbed into every POSIX-style zone specification. However, that's a behavior we'd really prefer to do without, since for our purposes the end effect is to render every POSIX-style zone name unsupported. Otherwise, the TZDEFRULES data is used only if the POSIX zone name specifies DST but doesn't include a transition date rule (e.g., "EST5EDT" rather than "EST5EDT,M3.2.0,M11.1.0"). That is a minority case for our purposes --- in particular, it never happens when tzload() invokes tzparse() to interpret a transition date rule string found in a tzdata zone file. Hence, if we legislate that we're going to ignore leap-second data from "posixrules", we can postpone the TZDEFRULES load into the path where we actually need to substitute for a missing date rule string. That means it will never happen at all in common scenarios, making it reasonable to dynamically allocate the cache space when it does happen. Even when the data is already loaded, this saves some cycles in the common code path since we avoid a memcpy of 23KB or so. And, IMO at least, this is a less ugly hack on the IANA logic than what we had before, since it's not messing with the lastditch-vs-regular code paths. Back-patch to all supported branches, not so much because this is a critical change as that I want to keep all our copies of the IANA timezone code in sync. Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de 17 October 2018, 16:26:48 UTC
1a69f73 Tom Lane 16 October 2018, 20:27:15 UTC Back off using -isysroot on Darwin. Rethink the solution applied in commit 5e2217131 to get PL/Tcl to build on macOS Mojave. I feared that adding -isysroot globally might have undesirable consequences, and sure enough Jakob Egger reported one: it complicates building extensions with a different Xcode version than was used for the core server. (I find that a risky proposition in general, but apparently it works most of the time, so we shouldn't break it if we don't have to.) We'd already adopted the solution for PL/Perl of inserting the sysroot path directly into the -I switches used to find Perl's headers, and we can do the same thing for PL/Tcl by changing the -iwithsysroot switch that Apple's tclConfig.sh reports. This restricts the risks to PL/Perl and PL/Tcl themselves and directly-dependent extensions, which is a lot more pleasing in general than a global -isysroot switch. Along the way, tighten the test to see if we need to inject the sysroot path into $perl_includedir, as I'd speculated about upthread but not gotten round to doing. As before, back-patch to all supported versions. Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us 16 October 2018, 20:27:15 UTC
49a1c22 Tom Lane 16 October 2018, 17:56:58 UTC Avoid rare race condition in privileges.sql regression test. We created a temp table, then switched to a new session, leaving the old session to clean up its temp objects in background. If that took long enough, the eventual attempt to drop the user that owns the temp table could fail, as exhibited today by sidewinder. Fix by dropping the temp table explicitly when we're done with it. It's been like this for quite some time, so back-patch to all supported branches. Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2018-10-16%2014%3A45%3A00 16 October 2018, 17:56:58 UTC
5f920de Tom Lane 16 October 2018, 16:27:14 UTC Make PostgresNode.pm's poll_query_until() more chatty about failures. Reporting only the stderr is unhelpful when the problem is that the server output we're getting doesn't match what was expected. So we should report the query output too; and just for good measure, let's print the query we used and the output we expected. Back-patch to 9.5 where poll_query_until was introduced. Discussion: https://postgr.es/m/17913.1539634756@sss.pgh.pa.us 16 October 2018, 16:27:26 UTC
6d2c760 Tom Lane 16 October 2018, 16:01:19 UTC Improve stability of recently-added regression test case. Commit b5febc1d1 added a contrib/btree_gist test case that has been observed to fail in the buildfarm as a result of background auto-analyze updating stats and changing the selected plan. Forestall that by forcibly analyzing in foreground, instead. The new plan choice is just as good for our purposes, since we really only care that an index-only plan does not get selected. Back-patch to 9.5, like the previous patch. Discussion: https://postgr.es/m/14643.1539629304@sss.pgh.pa.us 16 October 2018, 16:01:19 UTC
d112682 Tom Lane 16 October 2018, 15:50:18 UTC Avoid statically allocating gmtsub()'s timezone workspace. localtime.c's "struct state" is a rather large object, ~23KB. We were statically allocating one for gmtsub() to use to represent the GMT timezone, even though that function is not at all heavily used and is never reached in most backends. Let's malloc it on-demand, instead. This does pose the question of how to handle a malloc failure, but there's already a well-defined error report convention here, ie set errno and return NULL. We have but one caller of pg_gmtime in HEAD, and two in back branches, neither of which were troubling to check for error. Make them do so. The possible errors are sufficiently unlikely (out-of-range timestamp, and now malloc failure) that I think elog() is adequate. Back-patch to all supported branches to keep our copies of the IANA timezone code in sync. This particular change is in a stanza that already differs from upstream, so it's a wash for maintenance purposes --- but only as long as we keep the branches the same. Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de 16 October 2018, 15:50:18 UTC
19f2008 Tom Lane 15 October 2018, 21:12:02 UTC Stamp 11.0. 15 October 2018, 21:12:02 UTC
db9034b Tom Lane 15 October 2018, 18:01:38 UTC Check for stack overrun in standard_ProcessUtility(). ProcessUtility can recurse, and indeed can be driven to infinite recursion, so it ought to have a check_stack_depth() call. This covers the reported bug (portal trying to execute itself) and a bunch of other cases that could perhaps arise somewhere. Per bug #15428 from Malthe Borch. Back-patch to all supported branches. Discussion: https://postgr.es/m/15428-b3c2915ec470b033@postgresql.org 15 October 2018, 18:01:38 UTC
6c6dead Peter Eisentraut 15 October 2018, 09:33:11 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 63764ec4ef426dc469efe1cbcd9f2c45ef9fbe95 15 October 2018, 09:33:11 UTC
d315639 Peter Eisentraut 15 October 2018, 07:48:49 UTC Fixes for "Glyph not available" warnings from FOP With the PostgreSQL 11 release notes acknowledgments list, FOP reported WARNING: Glyph "?" (0x144, nacute) not available in font "Times-Roman". WARNING: Glyph "?" (0x15e, Scedilla) not available in font "Times-Roman". WARNING: Glyph "?" (0x15f, scedilla) not available in font "Times-Roman". WARNING: Glyph "?" (0x131, dotlessi) not available in font "Times-Roman". This is because we have some new contributors whose names use letters that we haven't used before, and apparently FOP can't handle them out of the box. For now, just fix this by "unaccenting" those names. In the future, maybe this can be fixed better with a different font configuration. There is also another warning WARNING: Glyph "?" (0x3c0, pi) not available in font "Times-Roman". but that existed in previous releases and is not touched here. 15 October 2018, 07:52:34 UTC
1846bac Alexander Korotkov 14 October 2018, 21:40:17 UTC contrib/bloom documentation improvement This commit documents rounding of "length" parameter and absence of support for unique indexes and NULLs searching. Backpatch to 9.6 where contrib/bloom was introduced. Discussion: https://postgr.es/m/CAF4Au4wPQQ7EHVSnzcLjsbY3oLSzVk6UemZLD1Sbmwysy3R61g%40mail.gmail.com Author: Oleg Bartunov with minor editorialization by me Backpatch-through: 9.6 14 October 2018, 22:08:03 UTC
18781cd Michael Paquier 14 October 2018, 13:23:29 UTC Avoid duplicate XIDs at recovery when building initial snapshot On a primary, sets of XLOG_RUNNING_XACTS records are generated on a periodic basis to allow recovery to build the initial state of transactions for a hot standby. The set of transaction IDs is created by scanning all the entries in ProcArray. However it happens that its logic never counted on the fact that two-phase transactions finishing to prepare can put ProcArray in a state where there are two entries with the same transaction ID, one for the initial transaction which gets cleared when prepare finishes, and a second, dummy, entry to track that the transaction is still running after prepare finishes. This way ensures a continuous presence of the transaction so as callers of for example TransactionIdIsInProgress() are always able to see it as alive. So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase transaction finishes to prepare, the record can finish with duplicated XIDs, which is a state expected by design. If this record gets applied on a standby to initial its recovery state, then it would simply fail, so the odds of facing this failure are very low in practice. It would be tempting to change the generation of XLOG_RUNNING_XACTS so as duplicates are removed on the source, but this requires to hold on ProcArrayLock for longer and this would impact all workloads, particularly those using heavily two-phase transactions. XLOG_RUNNING_XACTS is also actually used only to initialize the standby state at recovery, so instead the solution is taken to discard duplicates when applying the initial snapshot. Diagnosed-by: Konstantin Knizhnik Author: Michael Paquier Discussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru Backpatch-through: 9.3 14 October 2018, 13:23:29 UTC
52f76a0 Tom Lane 14 October 2018, 01:39:20 UTC Doc: still further copy-editing for v11 release notes. Justin Pryzby and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com 14 October 2018, 01:39:32 UTC
e2002b4 Greg Stark 06 October 2018, 17:03:43 UTC Add "B" suffix for bytes to docs 6e7baa3227 and b06d8e58b5 added "B" as a valid suffix for GUC_UNIT_BYTES but neglected to add it to the docs. 13 October 2018, 21:32:54 UTC
d1fd757 Tom Lane 13 October 2018, 21:29:12 UTC Doc: further copy-editing for v11 release notes. Justin Pryzby, Jonathan S. Katz, and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com 13 October 2018, 21:29:25 UTC
4d00ee4 Tom Lane 13 October 2018, 20:42:58 UTC Doc: copy-editing for CREATE INDEX reference page. Justin Pryzby, Jonathan S. Katz, and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com 13 October 2018, 20:43:10 UTC
a31af25 Tom Lane 13 October 2018, 20:31:09 UTC Make an editing pass over v11 release notes. Set the release date. Do a bunch of copy-editing and markup improvement, rearrange some stuff into what seemed a more sensible order, move some things that did not seem to be in the right section. 13 October 2018, 20:31:09 UTC
184951a Tom Lane 12 October 2018, 23:33:56 UTC Remove abstime, reltime, tinterval tables from old regression databases. In the back branches, drop these tables after the regression tests are done with them. This fixes failures of cross-branch pg_upgrade testing caused by these types having been removed in v12. We do lose the ability to test dump/restore behavior with these types in the back branches, but the actual loss of code coverage seems to be nil given that there's nothing very special about these types. Discussion: https://postgr.es/m/20181009192237.34wjp3nmw7oynmmr@alap3.anarazel.de 12 October 2018, 23:33:56 UTC
3d05965 Tom Lane 12 October 2018, 18:26:56 UTC Simplify use of AllocSetContextCreate() wrapper macro. We can allow this macro to accept either abbreviated or non-abbreviated allocation parameters by making use of __VA_ARGS__. As noted by Andres Freund, it's unlikely that any compiler would have __builtin_constant_p but not __VA_ARGS__, so this gives up little or no error checking, and it avoids a minor but annoying API break for extensions. With this change, there is no reason for anybody to call AllocSetContextCreateExtended directly, so in HEAD I renamed it to AllocSetContextCreateInternal. It's probably too late for an ABI break like that in 11, though. Discussion: https://postgr.es/m/20181012170355.bhxi273skjt6sag4@alap3.anarazel.de 12 October 2018, 18:26:56 UTC
355684e Alvaro Herrera 12 October 2018, 15:36:26 UTC Correct attach/detach logic for FKs in partitions There was no code to handle foreign key constraints on partitioned tables in the case of ALTER TABLE DETACH; and if you happened to ATTACH a partition that already had an equivalent constraint, that one was ignored and a new constraint was created. Adding this to the fact that foreign key cloning reuses the constraint name on the partition instead of generating a new name (as it probably should, to cater to SQL standard rules about constraint naming within schemas), the result was a pretty poor user experience -- the most visible failure was that just detaching a partition and re-attaching it failed with an error such as ERROR: duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index" DETAIL: Key (conrelid, contypid, conname)=(26702, 0, test_result_asset_id_fkey) already exists. because it would try to create an identically-named constraint in the partition. To make matters worse, if you tried to drop the constraint in the now-independent partition, that would fail because the constraint was still seen as dependent on the constraint in its former parent partitioned table: ERROR: cannot drop inherited constraint "test_result_asset_id_fkey" of relation "test_result_cbsystem_0001_0050_monthly_2018_09" This fix attacks the problem from two angles: first, when the partition is detached, the constraint is also marked as independent, so the drop now works. Second, when the partition is re-attached, we scan existing constraints searching for one matching the FK in the parent, and if one exists, we link that one to the parent constraint. So we don't end up with a duplicate -- and better yet, we don't need to scan the referenced table to verify that the constraint holds. To implement this I made a small change to previously planner-only struct ForeignKeyCacheInfo to contain the constraint OID; also relcache now maintains the list of FKs for partitioned tables too. Backpatch to 11. Reported-by: Michael Vitale (bug #15425) Discussion: https://postgr.es/m/15425-2dbc9d2aa999f816@postgresql.org 12 October 2018, 15:38:03 UTC
88670a4 Andres Freund 10 October 2018, 20:53:02 UTC Fix logical decoding error when system table w/ toast is repeatedly rewritten. Repeatedly rewriting a mapped catalog table with VACUUM FULL or CLUSTER could cause logical decoding to fail with: ERROR, "could not map filenode \"%s\" to relation OID" To trigger the problem the rewritten catalog had to have live tuples with toasted columns. The problem was triggered as during catalog table rewrites the heap_insert() check that prevents logical decoding information to be emitted for system catalogs, failed to treat the new heap's toast table as a system catalog (because the new heap is not recognized as a catalog table via RelationIsLogicallyLogged()). The relmapper, in contrast to the normal catalog contents, does not contain historical information. After a single rewrite of a mapped table the new relation is known to the relmapper, but if the table is rewritten twice before logical decoding occurs, the relfilenode cannot be mapped to a relation anymore. Which then leads us to error out. This only happens for toast tables, because the main table contents aren't re-inserted with heap_insert(). The fix is simple, add a new heap_insert() flag that prevents logical decoding information from being emitted, and accept during decoding that there might not be tuple data for toast tables. Unfortunately that does not fix pre-existing logical decoding errors. Doing so would require not throwing an error when a filenode cannot be mapped to a relation during decoding, and that seems too likely to hide bugs. If it's crucial to fix decoding for an existing slot, temporarily changing the ERROR in ReorderBufferCommit() to a WARNING appears to be the best fix. Author: Andres Freund Discussion: https://postgr.es/m/20180914021046.oi7dm4ra3ot2g2kt@alap3.anarazel.de Backpatch: 9.4-, where logical decoding was introduced 10 October 2018, 20:53:02 UTC
4c67618 Tom Lane 08 October 2018, 21:24:40 UTC Stamp 11rc1. 08 October 2018, 21:24:40 UTC
1145c26 Tom Lane 08 October 2018, 20:16:36 UTC Advance transaction timestamp for intra-procedure transactions. Per discussion, this behavior seems less astonishing than not doing so. Peter Eisentraut and Tom Lane Discussion: https://postgr.es/m/20180920234040.GC29981@momjian.us 08 October 2018, 20:16:36 UTC
8569ef6 Alvaro Herrera 08 October 2018, 13:36:33 UTC Silence compiler warning in Assert() gcc 6.3 does not whine about this mistake I made in 39808e8868c8 but evidently lots of other compilers do, according to Michael Paquier, Peter Eisentraut, Arthur Zakirov, Tomas Vondra. Discussion: too many to list 08 October 2018, 13:36:33 UTC
69ff26b Peter Eisentraut 08 October 2018, 10:03:54 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 64b916c6c8a34d9e6aad88e78cc2356a941f1335 08 October 2018, 10:03:54 UTC
c2055a4 Peter Eisentraut 05 October 2018, 12:14:03 UTC Track procedure calls in pg_stat_user_functions This was forgotten when procedures were implemented. Reported-by: Lukas Fittl <lukas@fittl.com> 08 October 2018, 09:23:07 UTC
c8ed820 Michael Paquier 08 October 2018, 08:56:13 UTC Improve two error messages related to foreign keys on partitioned tables Error messages for creating a foreign key on a partitioned table using ONLY or NOT VALID were wrong in mentioning the objects they worked on. This commit adds on the way some regression tests missing for those cases. Author: Laurenz Albe Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/c11c05810a9ed65e9b2c817a9ef442275a32fe80.camel@cybertec.at 08 October 2018, 08:57:52 UTC
4d7c740 Magnus Hagander 08 October 2018, 06:57:24 UTC Fix speling error Reported by Alexander Lakhin in bug #15423 08 October 2018, 07:05:05 UTC
1c7f585 Alvaro Herrera 07 October 2018, 01:13:19 UTC Fix catalog insertion order for ATTACH PARTITION Commit 2fbdf1b38bc changed the order in which we inserted catalog rows when creating partitions, so that we could remove an unsightly hack required for untimely relcache invalidations. However, that commit only changed the ordering for CREATE TABLE PARTITION OF, and left ALTER TABLE ATTACH PARTITION unchanged, so the latter can be affected when catalog invalidations occur, for instance when the partition key involves an SQL function. Reported-by: Rajkumar Raghuwanshi Author: Amit Langote Reviewed-by: Michaël Paquier Discussion: https://postgr.es/m/CAKcux6=nTz9KSfTr_6Z2mpzLJ_09JN-rK6=dWic6gGyTSWueyQ@mail.gmail.com 07 October 2018, 01:13:19 UTC
1a852f7 Alvaro Herrera 06 October 2018, 22:17:46 UTC Fix event triggers for partitioned tables Index DDL cascading on partitioned tables introduced a way for ALTER TABLE to be called reentrantly. This caused an an important deficiency in event trigger support to be exposed: on exiting the reentrant call, the alter table state object was clobbered, causing a crash when the outer alter table tries to finalize its processing. Fix the crash by creating a stack of event trigger state objects. There are still ways to cause things to misbehave (and probably other crashers) with more elaborate tricks, but at least it now doesn't crash in the obvious scenario. Backpatch to 9.5, where DDL deparsing of event triggers was introduced. Reported-by: Marco Slot Authors: Michaël Paquier, Álvaro Herrera Discussion: https://postgr.es/m/CANNhMLCpi+HQ7M36uPfGbJZEQLyTy7XvX=5EFkpR-b1bo0uJew@mail.gmail.com 06 October 2018, 22:17:46 UTC
6bf278d Tom Lane 06 October 2018, 16:00:09 UTC Propagate xactStartTimestamp and stmtStartTimestamp to parallel workers. Previously, a worker process would establish values for these based on its own start time. In v10 and up, this can trivially be shown to cause misbehavior of transaction_timestamp(), timestamp_in(), and related functions which are (perhaps unwisely?) marked parallel-safe. It seems likely that other behaviors might diverge from what happens in the parent as well. It's not as trivial to demonstrate problems in 9.6 or 9.5, but I'm sure it's still possible, so back-patch to all branches containing parallel worker infrastructure. In HEAD only, mark now() and statement_timestamp() as parallel-safe (other affected functions already were). While in theory we could still squeeze that change into v11, it doesn't seem important enough to force a last-minute catversion bump. Konstantin Knizhnik, whacked around a bit by me Discussion: https://postgr.es/m/6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru 06 October 2018, 16:00:09 UTC
c905b67 Michael Paquier 06 October 2018, 05:59:52 UTC Assign constraint name when cloning FK definition for partitions This is for example used when attaching a partition to a partitioned table which includes foreign keys, and in this case the constraint name has been missing in the data cloned. This could lead to hard crashes, as when validating the foreign key constraint, the constraint name is always expected. Particularly, when using log_min_messages >= DEBUG1, a log message would be generated with this unassigned constraint name, leading to an assertion failure on HEAD. While on it, rename a variable in ATExecAttachPartition which was declared twice with the same name. Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/20181005042236.GG1629@paquier.xyz Backpatch-through: 11 06 October 2018, 05:59:52 UTC
076cfff Bruce Momjian 05 October 2018, 21:20:24 UTC doc: update PG 11 release notes Discussion: https://postgr.es/m/1f5b2e66-7ba8-98ec-c06a-aee9ff33f050@postgresql.org Author: Jonathan S. Katz Backpatch-through: 11 05 October 2018, 21:20:24 UTC
67e7d4d Tom Lane 05 October 2018, 20:01:29 UTC Allow btree comparison functions to return INT_MIN. Historically we forbade datatype-specific comparison functions from returning INT_MIN, so that it would be safe to invert the sort order just by negating the comparison result. However, this was never really safe for comparison functions that directly return the result of memcmp(), strcmp(), etc, as POSIX doesn't place any such restriction on those library functions. Buildfarm results show that at least on recent Linux on s390x, memcmp() actually does return INT_MIN sometimes, causing sort failures. The agreed-on answer is to remove this restriction and fix relevant call sites to not make such an assumption; code such as "res = -res" should be replaced by "INVERT_COMPARE_RESULT(res)". The same is needed in a few places that just directly negated the result of memcmp or strcmp. To help find places having this problem, I've also added a compile option to nbtcompare.c that causes some of the commonly used comparators to return INT_MIN/INT_MAX instead of their usual -1/+1. It'd likely be a good idea to have at least one buildfarm member running with "-DSTRESS_SORT_INT_MIN". That's far from a complete test of course, but it should help to prevent fresh introductions of such bugs. This is a longstanding portability hazard, so back-patch to all supported branches. Discussion: https://postgr.es/m/20180928185215.ffoq2xrq5d3pafna@alap3.anarazel.de 05 October 2018, 20:01:29 UTC
6e526b7 Tom Lane 05 October 2018, 16:45:37 UTC Ensure that PLPGSQL_DTYPE_ROW variables have valid refname fields. Without this, the syntax-tree-dumping functions in pl_funcs.c crash, and there are other places that might be at risk too. Per report from Pavel Stehule. Looks like I broke this in commit f9263006d, so back-patch to v11. Discussion: https://postgr.es/m/CAFj8pRA+3f5n4642q2g8BXCKjbTd7yU9JMYAgDyHgozk6cQ-VA@mail.gmail.com 05 October 2018, 16:45:37 UTC
40159d9 Peter Eisentraut 05 October 2018, 15:10:19 UTC Remove redundant allocation Author: Nikita Glukhov <n.gluhov@postgrespro.ru> 05 October 2018, 15:26:58 UTC
ff347f8 Alvaro Herrera 04 October 2018, 14:37:20 UTC Fix duplicate primary keys in partitions When using the CREATE TABLE .. PARTITION OF syntax, it's possible to cause a partition to get two primary keys if the parent already has one. Tighten the check to disallow that. Reported-by: Rajkumar Raghuwanshi Author: Amul Sul Discussion: https://postgr.es/m/CAKcux6=OnSV3-qd8Gb6W=KPPwcCz6Fe_O_MQYjTa24__Xn8XxA@mail.gmail.com 04 October 2018, 14:40:10 UTC
e97c4d9 Andres Freund 03 October 2018, 19:48:37 UTC Fix issues around EXPLAIN with JIT. I (Andres) was more than a bit hasty in committing 33001fd7a7072d48327 after last minute changes, leading to a number of problems (jit output was only shown for JIT in parallel workers, and just EXPLAIN without ANALYZE didn't work). Lukas luckily found these issues quickly. Instead of combining instrumentation in in standard_ExecutorEnd(), do so on demand in the new ExplainPrintJITSummary(). Also update a documentation example of the JIT output, changed in 52050ad8ebec8d831. Author: Lukas Fittl, with minor changes by me Discussion: https://postgr.es/m/CAP53PkxmgJht69pabxBXJBM+0oc6kf3KHMborLP7H2ouJ0CCtQ@mail.gmail.com Backpatch: 11, where JIT compilation was introduced 03 October 2018, 20:11:44 UTC
ca5ca25 Amit Kapila 03 October 2018, 03:44:09 UTC MAXALIGN the target address where we store flattened value. The API (EOH_flatten_into) that flattens the expanded value representation expects the target address to be maxaligned. All it's usage adhere to that principle except when serializing datums for parallel query. Fix that usage. Diagnosed-by: Tom Lane Author: Tom Lane and Amit Kapila Backpatch-through: 9.6 Discussion: https://postgr.es/m/11629.1536550032@sss.pgh.pa.us 03 October 2018, 03:44:09 UTC
a051c19 Tom Lane 02 October 2018, 16:41:28 UTC Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two have no practical use and slow down the initialization of the argtypes array. Worse, they cause snprintf.c to consume far more stack space than was the design intention, possibly resulting in stack-overflow crashes. Standardize on 31, which is comfortably more than we need (it looks like no existing translatable message has more than about 10 parameters). I chose that, not 32, to make the array sizes powers of 2, for some possible small gain in speed of the memset. The lack of reported crashes suggests that the set of platforms we use snprintf.c on (in released branches) may have no overlap with the set where NL_ARGMAX has unreasonably large values. But that's not entirely clear, so back-patch to all supported branches. Per report from Mateusz Guzik (via Thomas Munro). Discussion: https://postgr.es/m/CAEepm=3VF=PUp2f8gU8fgZB22yPE_KBS0+e1AHAtQ=09schTHg@mail.gmail.com 02 October 2018, 16:41:28 UTC
419cc8a Tom Lane 02 October 2018, 15:54:12 UTC Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all rows of a catalog. has_column_privilege() had careless handling of the case where the table OID didn't exist. You might get something like this: select has_column_privilege(9999,'nosuchcol','select'); ERROR: column "nosuchcol" of relation "(null)" does not exist or you might get a crash, depending on the platform's printf's response to a null string pointer. In addition, while applying the column-number variant to a dropped column returned NULL as desired, applying the column-name variant did not: select has_column_privilege('mytable','........pg.dropped.2........','select'); ERROR: column "........pg.dropped.2........" of relation "mytable" does not exist It seems better to make this case return NULL as well. Also, the OID-accepting variants of has_foreign_data_wrapper_privilege, has_server_privilege, and has_tablespace_privilege didn't follow the principle of returning NULL for nonexistent OIDs. Superusers got TRUE, everybody else got an error. Per investigation of Jaime Casanova's report of a new crash in HEAD. These behaviors have been like this for a long time, so back-patch to all supported branches. Patch by me; thanks to Stephen Frost for discussion and review Discussion: https://postgr.es/m/CAJGNTeP=-6Gyqq5TN9OvYEydi7Fv1oGyYj650LGTnW44oAzYCg@mail.gmail.com 02 October 2018, 15:54:12 UTC
e9cff30 Michael Paquier 02 October 2018, 07:34:59 UTC Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/153838692816.2950.12001142346234155699@wrigleys.postgresql.org Backpatch-through: 9.3 02 October 2018, 07:34:59 UTC
3b983c3 Peter Eisentraut 01 October 2018, 21:02:55 UTC Change PROCEDURE to FUNCTION in CREATE EVENT TRIGGER syntax This was claimed to have been done in 0a63f996e018ac508c858e87fa39cc254a5db49f, but that actually only changed the documentation and not the grammar. (That commit did fully change it for CREATE TRIGGER.) 01 October 2018, 21:04:46 UTC
1f25c7a Tom Lane 01 October 2018, 15:51:07 UTC Fix tuple_data_split() to not open a relation without any lock. contrib/pageinspect's tuple_data_split() function thought it could get away with opening the referenced relation with NoLock. In practice there's no guarantee that the current session holds any lock on that rel (even if we just read a page from it), so that this is unsafe. Switch to using AccessShareLock. Also, postpone closing the relation, so that we needn't copy its tupdesc. Also, fix unsafe use of att_isnull() for attributes past the end of the tuple. Per testing with a patch that complains if we open a relation without holding any lock on it. I don't plan to back-patch that patch, but we should close the holes it identifies in all supported branches. Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us 01 October 2018, 15:51:07 UTC
4c98554 Tom Lane 01 October 2018, 15:39:13 UTC Fix ALTER COLUMN TYPE to not open a relation without any lock. If the column being modified is referenced by a foreign key constraint of another table, ALTER TABLE would open the other table (to re-parse the constraint's definition) without having first obtained a lock on it. This was evidently intentional, but that doesn't mean it's really safe. It's especially not safe in 9.3, which pre-dates use of MVCC scans for catalog reads, but even in current releases it doesn't seem like a good idea. We know we'll need AccessExclusiveLock shortly to drop the obsoleted constraint, so just get that a little sooner to close the hole. Per testing with a patch that complains if we open a relation without holding any lock on it. I don't plan to back-patch that patch, but we should close the holes it identifies in all supported branches. Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us 01 October 2018, 15:39:13 UTC
7871a36 Tom Lane 30 September 2018, 20:24:56 UTC Fix detection of the result type of strerror_r(). The method we've traditionally used, of redeclaring strerror_r() to see if the compiler complains of inconsistent declarations, turns out not to work reliably because some compilers only report a warning, not an error. Amazingly, this has gone undetected for years, even though it certainly breaks our detection of whether strerror_r succeeded. Let's instead test whether the compiler will take the result of strerror_r() as a switch() argument. It's possible this won't work universally either, but it's the best idea I could come up with on the spur of the moment. Back-patch of commit 751f532b9. Buildfarm results indicate that only icc-on-Linux actually has an issue here; perhaps the lack of field reports indicates that people don't build PG for production that way. Discussion: https://postgr.es/m/10877.1537993279@sss.pgh.pa.us 30 September 2018, 20:24:56 UTC
a8fb03f Tom Lane 28 September 2018, 20:12:13 UTC Improve error reporting for unsupported effective_io_concurrency setting. Give a specific error complaining about lack of posix_fadvise() when someone tries to set effective_io_concurrency > 0 on platforms without that. This probably isn't worth extensive back-patching, but I (tgl) felt cramming it into v11 was reasonable. James Robinson Discussion: https://postgr.es/m/153771876450.14994.560017943128223619@wrigleys.postgresql.org Discussion: https://postgr.es/m/A3942987-5BC7-4F05-B54D-2A0EC2914B33@jlr-photo.com 28 September 2018, 20:12:13 UTC
6c8671b Amit Kapila 28 September 2018, 06:54:09 UTC Fix assertion failure when updating full_page_writes for checkpointer. When the checkpointer receives a SIGHUP signal to update its configuration, it may need to update the shared memory for full_page_writes and need to write a WAL record for it. Now, it is quite possible that the XLOG machinery has not been initialized by that time and it will lead to assertion failure while doing that. Fix is to allow the initialization of the XLOG machinery outside critical section. This bug has been introduced by the commit 2c03216d83 which added the XLOG machinery initialization in RecoveryInProgress code path. Reported-by: Dilip Kumar Author: Dilip Kumar Reviewed-by: Michael Paquier and Amit Kapila Backpatch-through: 9.5 Discussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com 28 September 2018, 11:10:43 UTC
back to top