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
7aa5294 Tom Lane 11 May 2020, 21:16:09 UTC Stamp 9.5.22. 11 May 2020, 21:16:09 UTC
7ab65cd Peter Eisentraut 11 May 2020, 11:31:50 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 5c769f79a22d341c6ea364d879ce33a16b1154d7 11 May 2020, 11:31:50 UTC
52d849e Tom Lane 10 May 2020, 19:06:00 UTC Release notes for 12.3, 11.8, 10.13, 9.6.18, 9.5.22. 10 May 2020, 19:06:00 UTC
e3f5b14 Fujii Masao 07 April 2020, 15:49:29 UTC Prevent archive recovery from scanning non-existent WAL files. Previously when there were multiple timelines listed in the history file of the recovery target timeline, archive recovery searched all of them, starting from the newest timeline to the oldest one, to find the segment to read. That is, archive recovery had to continuously fail scanning the segment until it reached the timeline that the segment belonged to. These scans for non-existent segment could be harmful on the recovery performance especially when archival area was located on the remote storage and each scan could take a long time. To address the issue, this commit changes archive recovery so that it skips scanning the timeline that the segment to read doesn't belong to. Per discussion, back-patch to all supported versions. Author: Kyotaro Horiguchi, tweaked a bit by Fujii Masao Reviewed-by: David Steele, Pavel Suderevsky, Grigory Smolkin Discussion: https://postgr.es/m/16159-f5a34a3a04dc67e0@postgresql.org Discussion: https://postgr.es/m/20200129.120222.1476610231001551715.horikyota.ntt@gmail.com 09 May 2020, 03:19:47 UTC
4009571 Alvaro Herrera 08 May 2020, 23:38:46 UTC pg_restore: Provide file name with one failure message Almost all error messages already include file name where relevant, but this one had been overlooked. Repair. Backpatch to 9.5. Author: Euler Taveira <euler.taveira@2ndquadrant.com> Discussion: https://postgr.es/m/CAH503wA_VOrcKL_43p9atRejCDYmOZ8MzfK9S6TJrQqBqNeAXA@mail.gmail.com Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> 08 May 2020, 23:38:46 UTC
91d9746 Alvaro Herrera 06 May 2020, 16:29:41 UTC Heed lock protocol in DROP OWNED BY We were acquiring object locks then deleting objects one by one, instead of acquiring all object locks first, ignoring those that did not exist, and then deleting all objects together. The latter is the correct protocol to use, and what this commits changes to code to do. Failing to follow that leads to "cache lookup failed for relation XYZ" error reports when DROP OWNED runs concurrently with other DDL -- for example, a session termination that removes some temp tables. Author: Álvaro Herrera Reported-by: Mithun Chicklore Yogendra (Mithun CY) Reviewed-by: Ahsan Hadi, Tom Lane Discussion: https://postgr.es/m/CADq3xVZTbzK4ZLKq+dn_vB4QafXXbmMgDP3trY-GuLnib2Ai1w@mail.gmail.com 06 May 2020, 16:29:41 UTC
ad53d6e Michael Paquier 06 May 2020, 12:08:42 UTC Handle spaces for Python install location in MSVC scripts Attempting to use an installation path of Python that includes spaces caused the MSVC builds to fail. This fixes the issue by using the same quoting method as ad7595b for OpenSSL. Author: Victor Wagner Discussion: https://postgr.es/m/20200430150608.6dc6b8c4@antares.wagner.home Backpatch-through: 9.5 06 May 2020, 12:08:42 UTC
ad80d3e Tom Lane 01 May 2020, 21:28:01 UTC Get rid of trailing semicolons in C macro definitions. Writing a trailing semicolon in a macro is almost never the right thing, because you almost always want to write a semicolon after each macro call instead. (Even if there was some reason to prefer not to, pgindent would probably make a hash of code formatted that way; so within PG the rule should basically be "don't do it".) Thus, if we have a semi inside the macro, the compiler sees "something;;". Much of the time the extra empty statement is harmless, but it could lead to mysterious syntax errors at call sites. In perhaps an overabundance of neatnik-ism, let's run around and get rid of the excess semicolons whereever possible. The only thing worse than a mysterious syntax error is a mysterious syntax error that only happens in the back branches; therefore, backpatch these changes where relevant, which is most of them because most of these mistakes are old. (The lack of reported problems shows that this is largely a hypothetical issue, but still, it could bite us in some future patch.) John Naylor and Tom Lane Discussion: https://postgr.es/m/CACPNZCs0qWTqJ2QUSGJ07B7uvAvzMb-KbG2q+oo+J3tsWN5cqw@mail.gmail.com 01 May 2020, 21:28:01 UTC
b3824ca Andrew Gierth 25 April 2020, 04:10:05 UTC Fix error case for CREATE ROLE ... IN ROLE. CreateRole() was passing a Value node, not a RoleSpec node, for the newly-created role name when adding the role as a member of existing roles for the IN ROLE syntax. This mistake went unnoticed because the node in question is used only for error messages and is not accessed on non-error paths. In older pg versions (such as 9.5 where this was found), this results in an "unexpected node type" error in place of the real error. That node type check was removed at some point, after which the code would accidentally fail to fail on 64-bit platforms (on which accessing the Value node as if it were a RoleSpec would be mostly harmless) or give an "unexpected role type" error on 32-bit platforms. Fix the code to pass the correct node type, and add an lfirst_node assertion just in case. Per report on irc from user m1chelangelo. Backpatch all the way, because this error has been around for a long time. 25 April 2020, 04:10:05 UTC
3cdb45c Tom Lane 24 April 2020, 21:53:23 UTC Update Windows timezone name list to include currently-known zones. Thanks to Juan José Santamaría Flecha. Discussion: https://postgr.es/m/5752.1587740484@sss.pgh.pa.us 24 April 2020, 21:53:23 UTC
3f3ab18 Tom Lane 24 April 2020, 21:21:44 UTC Improve placement of "display name" comment in win32_tzmap[] entries. Sticking this comment at the end of the last line was a bad idea: it's not particularly readable, and it tempts pgindent to mess with line breaks within the comment, which in turn reveals that win32tzlist.pl's clean_displayname() does the wrong thing to clean up such line breaks. While that's not hard to fix, there's basically no excuse for this arrangement to begin with, especially since it makes the table layout needlessly vary across back branches with different pgindent rules. Let's just put the comment inside the braces, instead. This commit just moves and reformats the comments, and updates win32tzlist.pl to match; there's no actual data change. Per odd-looking results from Juan José Santamaría Flecha. Back-patch, since the point is to make win32_tzmap[] look the same in all supported branches again. Discussion: https://postgr.es/m/5752.1587740484@sss.pgh.pa.us 24 April 2020, 21:21:44 UTC
39006ae Tom Lane 24 April 2020, 14:54:47 UTC Update time zone data files to tzdata release 2020a. DST law changes in Morocco and the Canadian Yukon. Historical corrections for Shanghai. The America/Godthab zone is renamed to America/Nuuk to reflect current English usage; however, the old name remains available as a compatibility link. 24 April 2020, 14:55:23 UTC
a472699 Michael Paquier 24 April 2020, 02:34:16 UTC Remove some unstable parts from new TAP test for archive status check The test is proving to have timing issues when looking at archive status files on standbys after crash recovery, while other parts of the test rely on pg_stat_archiver as a wait point to make sure that a given state of the archiving is reached. The coverage is not heavily impacted by the removal those extra tests. Per reports from several buildfarm animals, like crake, piculet, culicidae and francolin. Discussion: https://postgr.es/m/20200424005929.GK33034@paquier.xyz Backpatch-through: 9.5 24 April 2020, 02:34:16 UTC
9eff116 Michael Paquier 23 April 2020, 23:48:55 UTC Fix handling of WAL segments ready to be archived during crash recovery 78ea8b5 has fixed an issue related to the recycling of WAL segments on standbys depending on archive_mode. However, it has introduced a regression with the handling of WAL segments ready to be archived during crash recovery, causing those files to be recycled without getting archived. This commit fixes the regression by tracking in shared memory if a live cluster is either in crash recovery or archive recovery as the handling of WAL segments ready to be archived is different in both cases (those WAL segments should not be removed during crash recovery), and by using this new shared memory state to decide if a segment can be recycled or not. Previously, it was not possible to know if a cluster was in crash recovery or archive recovery as the shared state was able to track only if recovery was happening or not, leading to the problem. A set of TAP tests is added to close the gap here, making sure that WAL segments ready to be archived are correctly handled when a cluster is in archive or crash recovery with archive_mode set to "on" or "always", for both standby and primary. Reported-by: Benoît Lobréau Author: Jehan-Guillaume de Rorthais Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/20200331172229.40ee00dc@firost Backpatch-through: 9.5 23 April 2020, 23:48:55 UTC
0b1ad96 Bruce Momjian 22 April 2020, 20:23:19 UTC docs: land height is "elevation", not "altitude" See https://mapscaping.com/blogs/geo-candy/what-is-the-difference-between-elevation-relief-and-altitude No patching of regression tests. Reported-by: taf1@cornell.edu Discussion: https://postgr.es/m/158506544539.679.2278386310645558048@wrigleys.postgresql.org Backpatch-through: 9.5 22 April 2020, 20:23:19 UTC
e5e295d Michael Paquier 21 April 2020, 22:28:04 UTC Fix memory leak in libpq when using sslmode=verify-full Checking if Subject Alternative Names (SANs) from a certificate match with the hostname connected to leaked memory after each lookup done. This is broken since acd08d7 that added support for SANs in SSL certificates, so backpatch down to 9.5. Author: Roman Peshkurov Reviewed-by: Hamid Akhtar, Michael Paquier, David Steele Discussion: https://postgr.es/m/CALLDf-pZ-E3mjxd5=bnHsDu9zHEOnpgPgdnO84E2RuwMCjjyPw@mail.gmail.com Backpatch-through: 9.5 21 April 2020, 22:28:04 UTC
36714f8 Tom Lane 21 April 2020, 19:58:43 UTC Fix possible crash during FATAL exit from reindexing. index.c supposed that it could just use a PG_TRY block to clean up the state associated with an active REINDEX operation. However, that code doesn't run if we do a FATAL exit --- for example, due to a SIGTERM shutdown signal --- while the REINDEX is happening. And that state does get consulted during catalog accesses, which makes it problematic if we do any catalog accesses during shutdown --- for example, to clean up any temp tables created in the session. If this combination of circumstances occurred, we could find ourselves trying to access already-freed memory. In debug builds that'd fairly reliably cause an assertion failure. In production we might often get away with it, but with some bad luck it could cause a core dump. Another possible bad outcome is an erroneous conclusion that an index-to-be-accessed is being reindexed; but it looks like that would be unlikely to have any consequences worse than failing to drop temp tables right away. (They'd still get dropped by the next session that uses that temp schema.) To fix, get rid of the use of PG_TRY here, and instead hook into the transaction abort mechanisms to clean up reindex state. Per bug #16378 from Alexander Lakhin. This has been wrong for a very long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/16378-7a70ca41b3ec2009@postgresql.org 21 April 2020, 19:58:43 UTC
f7b2e04 Bruce Momjian 21 April 2020, 01:41:12 UTC doc: change SGML markup "figure" to "example" Reported-by: Jürgen Purtz Discussion: https://postgr.es/m/709d7809-d7f4-8175-47f3-4d131341bba8@purtz.de Author: Jürgen Purtz Backpatch-through: 9.5 21 April 2020, 01:41:12 UTC
3ca1799 Andrew Dunstan 17 April 2020, 18:55:55 UTC Use a slightly more liberal regex to detect Visual Studio version Apparently in some language versions of Visual Studio nmake outputs some material after the version number and before the end of the line. This has been seen in Chinese versions. Therefore, we no longer demand that the version string comes at the end of a line. Per complaint from Cuiping Lin. Backpatch to all live branches. 17 April 2020, 18:57:15 UTC
46b1b63 Tom Lane 16 April 2020, 18:45:54 UTC Fix cache reference leak in contrib/sepgsql. fixup_whole_row_references() did the wrong thing with a dropped column, resulting in a commit-time warning about a cache reference leak. I (tgl) added a test case exercising this, but back-patched the test only as far as v10; the patch didn't apply cleanly to 9.6 and it didn't seem worth the trouble to adapt it. The bug is pretty old though, so apply the code change all the way back. Michael Luo, with cosmetic improvements by me Discussion: https://postgr.es/m/BYAPR08MB5606D1453D7F50E2AF4D2FD29AD80@BYAPR08MB5606.namprd08.prod.outlook.com 16 April 2020, 18:45:54 UTC
30ce863 Tom Lane 11 April 2020, 16:29:06 UTC Clear dangling pointer to avoid bogus EXPLAIN printout in a corner case. ExecReScanHashJoin will destroy the join's hash table if it expects that the inner relation will produce different rows on rescan. Up to now it's not bothered to clear the additional pointer to that hash table that exists in the child HashState node. However, it's possible for the query to terminate without building a fresh hash table (this happens if the outer relation is found to be empty during the final rescan). So we can end with a dangling pointer to a deleted hash table. That was harmless originally, but since 9.0 EXPLAIN ANALYZE has used that pointer to print hash table statistics. In debug builds this reproducibly results in garbage statistics. In non-debug builds there's frequently no ill effects, but in principle one could get wrong EXPLAIN ANALYZE output, or perhaps even a crash if free() has released the hashtable memory back to the OS. To fix, just make sure we clear the additional pointer when destroying the hash table. In problematic cases, EXPLAIN ANALYZE will then print no hashtable statistics (reverting to its pre-9.0 behavior). This isn't ideal, but since the problem manifests only in unusual corner cases, it's hard to justify taking any risks to do better in the back branches. A follow-on patch will improve matters in HEAD. Konstantin Knizhnik and Tom Lane, per diagnosis by Thomas Munro of a trouble report from Alvaro Herrera. Discussion: https://postgr.es/m/20200323165059.GA24950@alvherre.pgsql 11 April 2020, 16:29:06 UTC
2cab4ad Tom Lane 10 April 2020, 17:12:58 UTC Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/834603375.3470346.1586482852542@mail.yahoo.com 10 April 2020, 17:12:58 UTC
7b99e46 Tom Lane 10 April 2020, 14:44:10 UTC Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/158647836143.655.9853963229391401576@wrigleys.postgresql.org 10 April 2020, 14:44:10 UTC
564c1e6 Tom Lane 08 April 2020, 15:23:40 UTC Fix pg_dump/pg_restore to restore event trigger comments later. Repair an oversight in commit 8728b2c70: if we're postponing restore of event triggers to the end, we must also postpone restoring any comments on them, since of course we cannot create the comments first. (This opens yet another opportunity for an event trigger to bollix the restore, but there's no help for that.) Per bug #16346 from Alexander Lakhin. Like the previous commit, back-patch to all supported branches. Hamid Akhtar and Tom Lane Discussion: https://postgr.es/m/16346-6210ad7a0ea81be1@postgresql.org 08 April 2020, 15:23:40 UTC
ebd194a Tom Lane 08 April 2020, 00:50:02 UTC Fix circle_in to accept "(x,y),r" as it's advertised to do. Our documentation describes four allowed input syntaxes for circles, but the regression tests tried only three ... with predictable consequences. Remarkably, this has been wrong since the circle datatype was added in 1997, but nobody noticed till now. David Zhang, with some help from me Discussion: https://postgr.es/m/332c47fa-d951-7574-b5cc-a8f7f7201202@highgo.ca 08 April 2020, 00:50:02 UTC
dbb1210 Tom Lane 07 April 2020, 20:30:55 UTC Adjust bytea get_bit/set_bit to cope with bytea strings > 256MB. Since the existing bit number argument can't exceed INT32_MAX, it's not possible for these functions to manipulate bits beyond the first 256MB of a bytea value. However, it'd be good if they could do at least that much, and not fall over entirely for longer bytea values. Adjust the comparisons to be done in int64 arithmetic so that works. Also tweak the error reports to show sane values in case of overflow. Also add some test cases to improve the miserable code coverage of these functions. Apply patch to back branches only; HEAD has a better solution as of commit 26a944cf2. Extracted from a much larger patch by Movead Li Discussion: https://postgr.es/m/20200312115135445367128@highgo.ca 07 April 2020, 20:30:55 UTC
e82b6e0 Tom Lane 06 April 2020, 16:29:54 UTC Stabilize new GIN test case in 9.5 branch. In 9.6 and up, gin_test_tbl has autovacuum_enabled = off thanks to commit f8a1c1d5a. 9.5 lacked that, which allowed autovacuum to bollix the results of the test case added by commit 8150f7813. We could fool with disabling seqscan around that test, but making this branch look more like the later ones seems a better answer. Per buildfarm member protosciurus. (I'm not very sure why protosciurus is the only animal to report this so far; but it'd clearly be a timing-related failure, so it's not astonishing that only some machines would show it.) 06 April 2020, 16:29:54 UTC
3f77a67 Michael Paquier 06 April 2020, 02:06:07 UTC Preserve clustered index after rewrites with ALTER TABLE A table rewritten by ALTER TABLE would lose tracking of an index usable for CLUSTER. This setting is tracked by pg_index.indisclustered and is controlled by ALTER TABLE, so some extra work was needed to restore it properly. Note that ALTER TABLE only marks the index that can be used for clustering, and does not do the actual operation. Author: Amit Langote, Justin Pryzby Reviewed-by: Ibrar Ahmed, Michael Paquier Discussion: https://postgr.es/m/20200202161718.GI13621@telsasoft.com Backpatch-through: 9.5 06 April 2020, 02:06:07 UTC
a850063 Andres Freund 06 April 2020, 00:47:30 UTC Use TransactionXmin instead of RecentGlobalXmin in heap_abort_speculative(). There's a very low risk that RecentGlobalXmin could be far enough in the past to be older than relfrozenxid, or even wrapped around. Luckily the consequences of that having happened wouldn't be too bad - the page wouldn't be pruned for a while. Avoid that risk by using TransactionXmin instead. As that's announced via MyPgXact->xmin, it is protected against wrapping around (see code comments for details around relfrozenxid). Author: Andres Freund Discussion: https://postgr.es/m/20200328213023.s4eyijhdosuc4vcj@alap3.anarazel.de Backpatch: 9.5- 06 April 2020, 00:48:43 UTC
72b2b9c Peter Eisentraut 05 April 2020, 08:02:00 UTC Save errno across LWLockRelease() calls Fixup for "Drop slot's LWLock before returning from SaveSlotToPath()" Reported-by: Michael Paquier <michael@paquier.xyz> 05 April 2020, 08:05:18 UTC
8150f78 Tom Lane 03 April 2020, 17:15:30 UTC Fix bugs in gin_fuzzy_search_limit processing. entryGetItem()'s three code paths each contained bugs associated with filtering the entries for gin_fuzzy_search_limit. The posting-tree path failed to advance "advancePast" after having decided to filter an item. If we ran out of items on the current page and needed to advance to the next, what would actually happen is that entryLoadMoreItems() would re-load the same page. Eventually, the random dropItem() test would accept one of the same items it'd previously rejected, and we'd move on --- but it could take awhile with small gin_fuzzy_search_limit. To add insult to injury, this case would inevitably cause entryLoadMoreItems() to decide it needed to re-descend from the root, making things even slower. The posting-list path failed to implement gin_fuzzy_search_limit filtering at all, so that all entries in the posting list would be returned. The bitmap-result path used a "gotitem" variable that it failed to update in the one place where it'd actually make a difference, ie at the one "continue" statement. I think this was unreachable in practice, because if we'd looped around then it shouldn't be the case that the entries on the new page are before advancePast. Still, the "gotitem" variable was contributing nothing to either clarity or correctness, so get rid of it. Refactor all three loops so that the termination conditions are more alike and less unreadable. The code coverage report showed that we had no coverage at all for the re-descend-from-root code path in entryLoadMoreItems(), which seems like a very bad thing, so add a test case that exercises it. We also had exactly no coverage for gin_fuzzy_search_limit, so add a simplistic test case that at least hits those code paths a little bit. Back-patch to all supported branches. Adé Heyward and Tom Lane Discussion: https://postgr.es/m/CAEknJCdS-dE1Heddptm7ay2xTbSeADbkaQ8bU2AXRCVC2LdtKQ@mail.gmail.com 03 April 2020, 17:15:30 UTC
82bc56e Tom Lane 03 April 2020, 15:24:56 UTC Fix bogus CALLED_AS_TRIGGER() defenses. contrib/lo's lo_manage() thought it could use trigdata->tg_trigger->tgname in its error message about not being called as a trigger. That naturally led to a core dump. unique_key_recheck() figured it could Assert that fcinfo->context is a TriggerData node in advance of having checked that it's being called as a trigger. That's harmless in production builds, and perhaps not that easy to reach in any case, but it's logically wrong. The first of these per bug #16340 from William Crowell; the second from manual inspection of other CALLED_AS_TRIGGER call sites. Back-patch the lo.c change to all supported branches, the other to v10 where the thinko crept in. Discussion: https://postgr.es/m/16340-591c7449dc7c8c47@postgresql.org 03 April 2020, 15:24:56 UTC
d269f85 Bruce Momjian 02 April 2020, 21:42:09 UTC doc: remove unnecessary INNER keyword A join that was added in commit 9b2009c4cf that did not use the INNER keyword but the existing query used it. It was cleaner to remove the existing INNER keyword. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/a1ffbfda-59d2-5732-e5fb-3df8582b6434@2ndquadrant.com Backpatch-through: 9.5 02 April 2020, 21:42:09 UTC
bf09e83 Bruce Momjian 02 April 2020, 21:27:42 UTC doc: remove comma, related to commit 92d31085e9 Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/750b8832-d123-7f9b-931e-43ce8321b2d7@2ndquadrant.com Backpatch-through: 9.5 02 April 2020, 21:27:42 UTC
1163819 Bruce Momjian 31 March 2020, 22:44:29 UTC doc: remove mention of bitwise operators as solely type-limited There are other operators that have limited number data type support, so just remove the sentence. Reported-by: Sergei Agalakov Discussion: https://postgr.es/m/158032651854.19851.16261832706661813796@wrigleys.postgresql.org Backpatch-through: 9.5 31 March 2020, 22:44:29 UTC
7b7b60f Bruce Momjian 31 March 2020, 22:10:39 UTC doc: clarify hierarchy of objects: global, db, schema, etc. The previous wording was confusing because it wasn't in decreasing order and had to backtrack. Also clarify role/user wording. Reported-by: jbird@nuna.com Discussion: https://postgr.es/m/158057750885.1123.2806779262588618988@wrigleys.postgresql.org Backpatch-through: 9.5 31 March 2020, 22:10:39 UTC
a1e42d8 Bruce Momjian 31 March 2020, 21:52:48 UTC doc: restore wording from recent patch "rolled back to" Reported-by: Tom Lane Discussion: https://postgr.es/m/31072.1585690490@sss.pgh.pa.us Backpatch-through: 9.5 - 12 31 March 2020, 21:52:48 UTC
8a2ad9d Bruce Momjian 31 March 2020, 21:27:32 UTC doc: clarify when row-level locks are released They are released just like table-level locks. Also clean up wording. Reported-by: me@sillymon.ch Discussion: https://postgr.es/m/158074944048.1095.4309647363871637715@wrigleys.postgresql.org Backpatch-through: 9.5 31 March 2020, 21:27:32 UTC
dd9f34c Bruce Momjian 31 March 2020, 21:16:33 UTC doc: add namespace column to pg_buffercache example query Without the namespace, the table name could be ambiguous. Reported-by: adunham@arbormetrix.com Discussion: https://postgr.es/m/158155175140.23798.2189464781144503491@wrigleys.postgresql.org Backpatch-through: 9.5 31 March 2020, 21:16:33 UTC
a91e8e1 Bruce Momjian 31 March 2020, 20:31:44 UTC doc: adjust UPDATE/DELETE's FROM/USING to match SELECT's FROM Previously the syntax and wording were unclear. Reported-by: Alexey Bashtanov Discussion: https://postgr.es/m/968d4724-8e58-788f-7c45-f7b1813824cc@imap.cc Backpatch-through: 9.5 31 March 2020, 20:31:44 UTC
cffa57f Tom Lane 31 March 2020, 15:37:44 UTC Back-patch addition of stack overflow and interrupt checks for lquery. Experimentation shows that it's not hard at all to drive the old implementation of "ltree ~ lquery" match to stack overflow, so throw in a check_stack_depth() call, as I just did in HEAD. I wasn't able to make it take a long time, because all the pathological cases I tried hit stack overflow first; but I bet there are some others that do take a long time, so add CHECK_FOR_INTERRUPTS() too. Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com 31 March 2020, 15:37:44 UTC
6dac1e8 Tom Lane 30 March 2020, 15:14:58 UTC Be more careful about extracting encoding from locale strings on Windows. GetLocaleInfoEx() can fail on strings that setlocale() was perfectly happy with. A common way for that to happen is if the locale string is actually a Unix-style string, say "et_EE.UTF-8". In that case, what's after the dot is an encoding name, not a Windows codepage number; blindly treating it as a codepage number led to failure, with a fairly silly error message. Hence, check to see if what's after the dot is all digits, and if not, treat it as a literal encoding name rather than a codepage number. This will do the right thing with many Unix-style locale strings, and produce a more sensible error message otherwise. Somewhat independently of that, treat a zero (CP_ACP) result from GetLocaleInfoEx() as meaning that we must use UTF-8 encoding. Back-patch to all supported branches. Juan José Santamaría Flecha Discussion: https://postgr.es/m/24905.1585445371@sss.pgh.pa.us 30 March 2020, 15:14:58 UTC
4bdb3f3 Tom Lane 29 March 2020, 22:54:19 UTC Doc: correct misstatement about ltree label maximum length. The documentation says that the max length is 255 bytes, but code inspection says it's actually 255 characters; and relevant lengths are stored as uint16 so that that works. 29 March 2020, 22:54:19 UTC
8e1e630 Tom Lane 28 March 2020, 21:09:52 UTC Protect against overflow of ltree.numlevel and lquery.numlevel. These uint16 fields could be overflowed by excessively long input, producing strange results. Complain for invalid input. Likewise check for out-of-range values of the repeat counts in lquery. (We don't try too hard on that one, notably not bothering to detect if atoi's result has overflowed.) Also detect length overflow in ltree_concat. In passing, be more consistent about whether "syntax error" messages include the type name. Also, clarify the documentation about what the size limit is. This has been broken for a long time, so back-patch to all supported branches. Nikita Glukhov, reviewed by Benjie Gillam and Tomas Vondra Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com 28 March 2020, 21:09:52 UTC
820f21a Andres Freund 28 March 2020, 18:52:11 UTC Ensure snapshot is registered within ScanPgRelation(). In 9.4 I added support to use a historical snapshot in ScanPgRelation(), while adding logical decoding. Unfortunately a conflict with the concurrent removal of SnapshotNow was incorrectly resolved, leading to an unregistered snapshot being used. It is not correct to use an unregistered (or non-active) snapshot for anything non-trivial, because catalog invalidations can cause the snapshot to be invalidated. Luckily it seems unlikely to actively cause problems in practice, as ScanPgRelation() requires that we already have a lock on the relation, we only look for a single row, and we don't appear to rely on the result's tid to be correct. It however is clearly wrong and potential negative consequences would likely be hard to find. So it seems worth backpatching the fix, even without a concrete hazard. Discussion: https://postgr.es/m/20200229052459.wzhqnbhrriezg4v2@alap3.anarazel.de Backpatch: 9.5- 28 March 2020, 19:05:05 UTC
4bfacc5 Tom Lane 26 March 2020, 22:06:56 UTC Ensure that plpgsql cleans up cleanly during parallel-worker exit. plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT respectively, since its goal is to do process-local cleanup. This oversight caused plpgsql's end-of-transaction cleanup to not get done in parallel workers. Since a parallel worker will exit just after the transaction cleanup, the effects of this are limited. I couldn't find any case in the core code with user-visible effects, but perhaps there are some in extensions. In any case it's wrong, so let's fix it before it bites us not after. In passing, add some comments around the handling of expression evaluation resources in DO blocks. There's no live bug there, but it's quite unobvious what's happening; at least I thought so. This isn't related to the other issue, except that I found both things while poking at expression-evaluation performance. Back-patch the plpgsql_xact_cb fix to 9.5 where those event types were introduced, and the DO-block commentary to v11 where DO blocks gained the ability to issue COMMIT/ROLLBACK. Discussion: https://postgr.es/m/10353.1585247879@sss.pgh.pa.us 26 March 2020, 22:06:56 UTC
ce28a43 Peter Eisentraut 26 March 2020, 10:51:39 UTC Drop slot's LWLock before returning from SaveSlotToPath() When SaveSlotToPath() is called with elevel=LOG, the early exits didn't release the slot's io_in_progress_lock. This could result in a walsender being stuck on the lock forever. A possible way to get into this situation is if the offending code paths are triggered in a low disk space situation. Author: Pavan Deolasee <pavan.deolasee@2ndquadrant.com> Reported-by: Craig Ringer <craig@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/56a138c5-de61-f553-7e8f-6789296de785%402ndquadrant.com 26 March 2020, 13:08:15 UTC
2af8894 Tom Lane 23 March 2020, 16:42:16 UTC Doc: explain that LIKE et al can be used in ANY (sub-select) etc. This wasn't stated anywhere, and it's perhaps not that obvious, since we get questions about it from time to time. Also undocumented was that the parser actually translates these into operators. Discussion: https://postgr.es/m/CAFj8pRBkvZ71BqGKZnBBG4=0cKG+s50Dy+DYmrizUKEpAtdc+w@mail.gmail.com 23 March 2020, 16:42:16 UTC
5f9eace Tom Lane 23 March 2020, 15:58:01 UTC Fix our getopt_long's behavior for a command line argument of just "-". src/port/getopt_long.c failed on such an argument, always seeing it as an unrecognized switch. This is unhelpful; better is to treat such an item as a non-switch argument. That behavior is what we find in GNU's getopt_long(); it's what src/port/getopt.c does; and it is required by POSIX for getopt(), which getopt_long() ought to be generally a superset of. Moreover, it's expected by ecpg, which intends an argument of "-" to mean "read from stdin". So fix it. Also add some documentation about ecpg's behavior in this area, since that was miserably underdocumented. I had to reverse-engineer it from the code. Per bug #16304 from James Gray. Back-patch to all supported branches, since this has been broken forever. Discussion: https://postgr.es/m/16304-c662b00a1322db7f@postgresql.org 23 March 2020, 15:58:01 UTC
87d0f48 Michael Paquier 23 March 2020, 04:38:35 UTC Doc: Fix type of some storage parameters in CREATE TABLE page autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor have been documented as "float4", but "floating type" is used in this case for GUCs and relation options in the documentation. Author: Atsushi Torikoshi Discussion: https://postgr.es/m/CACZ0uYFf_p9BpbjLccx3CA=eM1Hk2Te=ULY4iptGLUhL-JxCPA@mail.gmail.com Backpatch-through: 9.5 23 March 2020, 04:38:35 UTC
b31e96b Noah Misch 22 March 2020, 16:24:09 UTC Revert "Skip WAL for new relfilenodes, under wal_level=minimal." This reverts commit cb2fd7eac285b1b0a24eeb2b8ed4456b66c5a09f. Per numerous buildfarm members, it was incompatible with parallel query, and a test case assumed LP64. Back-patch to 9.5 (all supported versions). Discussion: https://postgr.es/m/20200321224920.GB1763544@rfd.leadboat.com 22 March 2020, 16:24:15 UTC
9db4b9d Noah Misch 21 March 2020, 16:38:26 UTC Skip WAL for new relfilenodes, under wal_level=minimal. Until now, only selected bulk operations (e.g. COPY) did this. If a given relfilenode received both a WAL-skipping COPY and a WAL-logged operation (e.g. INSERT), recovery could lose tuples from the COPY. See src/backend/access/transam/README section "Skipping WAL for New RelFileNode" for the new coding rules. Maintainers of table access methods should examine that section. To maintain data durability, just before commit, we choose between an fsync of the relfilenode and copying its contents to WAL. A new GUC, wal_skip_threshold, guides that choice. If this change slows a workload that creates small, permanent relfilenodes under wal_level=minimal, try adjusting wal_skip_threshold. Users setting a timeout on COMMIT may need to adjust that timeout, and log_min_duration_statement analysis will reflect time consumption moving to COMMIT from commands like COPY. Internally, this requires a reliable determination of whether RollbackAndReleaseCurrentSubTransaction() would unlink a relation's current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the specification of rd_createSubid such that the field is zero when a new rel has an old rd_node. Make relcache.c retain entries for certain dropped relations until end of transaction. Back-patch to 9.5 (all supported versions). This introduces a new WAL record type, XLOG_GIST_ASSIGN_LSN, without bumping XLOG_PAGE_MAGIC. As always, update standby systems before master systems. This changes sizeof(RelationData) and sizeof(IndexStmt), breaking binary compatibility for affected extensions. (The most recent commit to affect the same class of extensions was 089e4d405d0f3b94c74a2c6a54357a84a681754b.) Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert Haas. Heikki Linnakangas and Michael Paquier implemented earlier designs that materially clarified the problem. Reviewed, in earlier designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane, Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout. Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org 21 March 2020, 16:38:36 UTC
e0dd086 Noah Misch 21 March 2020, 16:38:33 UTC Back-patch log_newpage_range(). Back-patch a subset of commit 9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b to v11, v10, 9.6, and 9.5. Include the latest repairs to this function. Use a new XLOG_FPI_MULTI value instead of reusing XLOG_FPI. That way, if an older server reads WAL from this function, that server will PANIC instead of applying just one page of the record. The next commit adds a call to this function. Discussion: https://postgr.es/m/20200304.162919.898938381201316571.horikyota.ntt@gmail.com 21 March 2020, 16:38:35 UTC
978da2a Noah Misch 21 March 2020, 16:38:26 UTC During heap rebuild, lock any TOAST index until end of transaction. swap_relation_files() calls toast_get_valid_index() to find and lock this index, just before swapping with the rebuilt TOAST index. The latter function releases the lock before returning. Potential for mischief is low; a concurrent session can issue ALTER INDEX ... SET (fillfactor = ...), which is not alarming. Nonetheless, changing pg_class.relfilenode without a lock is unconventional. Back-patch to 9.5 (all supported versions), because another fix needs this. Discussion: https://postgr.es/m/20191226001521.GA1772687@rfd.leadboat.com 21 March 2020, 16:38:35 UTC
96dffcd Noah Misch 21 March 2020, 16:38:26 UTC Fix cosmetic blemishes involving rd_createSubid. Remove an obsolete comment from AtEOXact_cleanup(). Restore formatting of a comment in struct RelationData, mangled by the pgindent run in commit 9af4159fce6654aa0e081b00d02bca40b978745c. Back-patch to 9.5 (all supported versions), because another fix stacks on this. 21 March 2020, 16:38:35 UTC
39ceaa2 Bruce Momjian 21 March 2020, 00:19:32 UTC docs: use alias in WHERE clause of full text search example The current doc query specified an alias in the FROM clause and used in it the target list, but not in the WHERE clause. Reported-by: axykon@gmail.com Discussion: https://postgr.es/m/158316348159.30450.16075357948244298217@wrigleys.postgresql.org Backpatch-through: 9.5 21 March 2020, 00:19:32 UTC
467b408 Andrew Dunstan 20 March 2020, 17:55:15 UTC Turn off deprecated bison warnings under MSVC These are disabled by the configure code, so this is just fixing an inconsistency in the MSVC code. Backpatch to all live branches. 20 March 2020, 18:03:31 UTC
2c9864e Bruce Momjian 19 March 2020, 19:20:55 UTC pg_upgrade: make get_major_server_version() err msg consistent This patch fixes the error message in get_major_server_version() to be "could not parse version file", and uses the full file path name, rather than just the data directory path. Also, commit 4109bb5de4 added the cause of the failure to the "could not open" error message, and improved quoting. This patch backpatches the "could not open" cause to PG 12, where it was first widely used, and backpatches the quoting fix in that patch to all supported releases. Reported-by: Tom Lane Discussion: https://postgr.es/m/87pne2w98h.fsf@wibble.ilmari.org Author: Dagfinn Ilmari Mannsåker Backpatch-through: 9.5 19 March 2020, 19:20:55 UTC
12034da Noah Misch 19 March 2020, 16:39:26 UTC Back-patch src/test/recovery and PostgresNode from 9.6 to 9.5. This omits 007_sync_rep.pl, which tests a feature new in 9.6. The only other change is to substitute "hot_standby" for "replica". A planned back-patch will use this suite to test its recovery behavior changes. Identified by Kyotaro Horiguchi, though I did not use his patch. Discussion: https://postgr.es/m/20200304.162919.898938381201316571.horikyota.ntt@gmail.com 19 March 2020, 16:39:26 UTC
c2c2e53 Tom Lane 18 March 2020, 15:04:48 UTC Doc: remove reference to nonexisting GUC from 9.5 release notes. idle_in_transaction_session_timeout doesn't exist before 9.6, so mentioning it in older branches' release notes is confusing. Lazy copy-and-paste on my (tgl's) part. Too late to do anything about 9.4, but we can usefully fix this in 9.5. Daniel Gustafsson Discussion: https://postgr.es/m/0980BAC2-C30E-4439-A1D0-BE4FA4EF5666@yesql.se 18 March 2020, 15:04:48 UTC
6bdfe42 Amit Kapila 18 March 2020, 04:40:27 UTC Add missing errcode() in a few ereport calls. This will allow to specifying SQLSTATE error code for the errors in the missing places. Reported-by: Sawada Masahiko Author: Sawada Masahiko Backpatch-through: 9.5 Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com 18 March 2020, 04:40:27 UTC
f99363e Tom Lane 17 March 2020, 19:05:17 UTC Doc: clarify behavior of "anyrange" pseudo-type. I noticed that we completely failed to document the restriction that an "anyrange" result type has to be inferred from an "anyrange" input. The docs also were less clear than they could be about the relationship between "anyrange" and "anyarray". It's been like this all along, so back-patch. 17 March 2020, 19:05:17 UTC
da25414 Tom Lane 17 March 2020, 01:05:29 UTC Avoid holding a directory FD open across assorted SRF calls. This extends the fixes made in commit 085b6b667 to other SRFs with the same bug, namely pg_logdir_ls(), pgrowlocks(), pg_timezone_names(), pg_ls_dir(), and pg_tablespace_databases(). Also adjust various comments and documentation to warn against expecting to clean up resources during a ValuePerCall SRF's final call. Back-patch to all supported branches, since these functions were all born broken. Justin Pryzby, with cosmetic tweaks by me Discussion: https://postgr.es/m/20200308173103.GC1357@telsasoft.com 17 March 2020, 01:05:29 UTC
5c3a700 Bruce Momjian 14 March 2020, 21:36:54 UTC C comment: correct commented bytes of max_cached_tuplebufs The comment said ~8MB, but it is actually ~64MB. Reported-by: Kuntal Ghosh Discussion: https://postgr.es/m/CAGz5QC+GGmHdnxp04B6wcLz2Zcd_HU+wCBrsPyOZP62-BJghig@mail.gmail.com Backpatch-through: 9.5-10 14 March 2020, 21:36:54 UTC
a1ef0f3 Tom Lane 14 March 2020, 18:42:22 UTC Restructure polymorphic-type resolution in funcapi.c. resolve_polymorphic_tupdesc() and resolve_polymorphic_argtypes() failed to cover the case of having to resolve anyarray given only an anyrange input. The bug was masked if anyelement was also used (as either input or output), which probably helps account for our not having noticed. While looking at this I noticed that resolve_generic_type() would produce the wrong answer if asked to make that same resolution. ISTM that resolve_generic_type() is confusingly defined and overly complex, so rather than fix it, let's just make funcapi.c do the specific lookups it requires for itself. With this change, resolve_generic_type() is not used anywhere, so remove it in HEAD. In the back branches, leave it alone (complete with bug) just in case any external code is using it. While we're here, make some other refactoring adjustments in funcapi.c with an eye to upcoming future expansion of the set of polymorphic types: * Simplify quick-exit tests by adding an overall have_polymorphic_result flag. This is about a wash now but will be a win when there are more flags. * Reduce duplication of code between resolve_polymorphic_tupdesc() and resolve_polymorphic_argtypes(). * Don't bother to validate correct matching of anynonarray or anyenum; the parser should have done that, and even if it didn't, just doing "return false" here would lead to a very confusing, off-point error message. (Really, "return false" in these two functions should only occur if the call_expr isn't supplied or we can't obtain data type info from it.) * For the same reason, throw an elog rather than "return false" if we fail to resolve a polymorphic type. The bug's been there since we added anyrange, so back-patch to all supported branches. Discussion: https://postgr.es/m/6093.1584202130@sss.pgh.pa.us 14 March 2020, 18:42:22 UTC
c15d350 Peter Eisentraut 13 March 2020, 10:28:11 UTC Preserve replica identity index across ALTER TABLE rewrite If an index was explicitly set as replica identity index, this setting was lost when a table was rewritten by ALTER TABLE. Because this setting is part of pg_index but actually controlled by ALTER TABLE (not part of CREATE INDEX, say), we have to do some extra work to restore it. Based-on-patch-by: Quan Zongliang <quanzongliang@gmail.com> Reviewed-by: Euler Taveira <euler.taveira@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/c70fcab2-4866-0d9f-1d01-e75e189db342@gmail.com 13 March 2020, 12:21:30 UTC
d22ac53 Thomas Munro 12 March 2020, 05:06:54 UTC Fix nextXid tracking bug on standbys (9.5-11 only). RecordKnownAssignedTransactionIds() should never move nextXid backwards. Before this commit, that could happen if some other code path had advanced it without advancing latestObservedXid. One consequence is that a well timed XLOG_CHECKPOINT_ONLINE could cause hot standby feedback messages to get confused and report an xmin from a future epoch, potentially allowing vacuum to run too soon on the primary. Repair, by making sure RecordKnownAssignedTransactionIds() can only move nextXid forwards. In release 12 and master, this was already done by commit 2fc7af5e, which consolidated similar code and straightened out this bug. Back-patch to supported releases before that. Author: Eka Palamadai <ekanatha@amazon.com> Discussion: https://postgr.es/m/98BB4805-D0A2-48E1-96F4-15014313EADC@amazon.com 12 March 2020, 05:15:59 UTC
0b02476 Tom Lane 09 March 2020, 18:58:11 UTC Fix pg_dump/pg_restore to restore event triggers later. Previously, event triggers were restored just after regular triggers (and FK constraints, which are basically triggers). This is risky since an event trigger, once installed, could interfere with subsequent restore commands. Worse, because event triggers don't have any particular dependencies on any post-data objects, a parallel restore would consider them eligible to be restored the moment the post-data phase starts, allowing them to also interfere with restoration of a whole bunch of objects that would have been restored before them in a serial restore. There's no way to completely remove the risk of a misguided event trigger breaking the restore, since if nothing else it could break other event triggers. But we can certainly push them to later in the process to minimize the hazard. To fix, tweak the RestorePass mechanism introduced by commit 3eb9a5e7c so that event triggers are handled as part of the post-ACL processing pass (renaming the "REFRESH" pass to "POST_ACL" to reflect its more general use). This will cause them to restore after everything except matview refreshes, which seems OK since matview refreshes really ought to run in the post-restore state of the database. In a parallel restore, event triggers and matview refreshes might be intermixed, but that seems all right as well. Also update the code and comments in pg_dump_sort.c so that its idea of how things are sorted agrees with what actually happens due to the RestorePass mechanism. This is mostly cosmetic: it'll affect the order of objects in a dump's TOC, but not the actual restore order. But not changing that would be quite confusing to somebody reading the code. Back-patch to all supported branches. Fabrízio de Royes Mello, tweaked a bit by me Discussion: https://postgr.es/m/CAFcNs+ow1hmFox8P--3GSdtwz-S3Binb6ZmoP6Vk+Xg=K6eZNA@mail.gmail.com 09 March 2020, 18:58:11 UTC
c9a47b8 Fujii Masao 09 March 2020, 15:14:43 UTC Fix bug that causes to report waiting in PS display twice, in hot standby. Previously "waiting" could appear twice via PS in case of lock conflict in hot standby mode. Specifically this issue happend when the delay in WAL application determined by max_standby_archive_delay and max_standby_streaming_delay had passed but it took more than 500 msec to cancel all the conflicting transactions. Especially we can observe this easily by setting those delay parameters to -1. The cause of this issue was that WaitOnLock() and ResolveRecoveryConflictWithVirtualXIDs() added "waiting" to the process title in that case. This commit prevents ResolveRecoveryConflictWithVirtualXIDs() from reporting waiting in case of lock conflict, to fix the bug. Back-patch to all back branches. Author: Masahiko Sawada Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CA+fd4k4mXWTwfQLS3RPwGr4xnfAEs1ysFfgYHvmmoUgv6Zxvmg@mail.gmail.com 09 March 2020, 15:23:22 UTC
74d32ef Fujii Masao 09 March 2020, 06:31:31 UTC Avoid assertion failure with targeted recovery in standby mode. At the end of recovery, standby mode is turned off to re-fetch the last valid record from archive or pg_wal. Previously, if recovery target was reached and standby mode was turned off while the current WAL source was stream, recovery could try to retrieve WAL file containing the last valid record unexpectedly from stream even though not in standby mode. This caused an assertion failure. That is, the assertion test confirms that WAL file should not be retrieved from stream if standby mode is not true. This commit moves back the current WAL source to archive if it's stream even though not in standby mode, to avoid that assertion failure. This issue doesn't cause the server to crash when built with assertion disabled. In this case, the attempt to retrieve WAL file from stream not in standby mode just fails. And then recovery tries to retrieve WAL file from archive or pg_wal. Back-patch to all supported branches. Author: Kyotaro Horiguchi Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/20200227.124830.2197604521555566121.horikyota.ntt@gmail.com 09 March 2020, 06:37:28 UTC
d013c0b Fujii Masao 03 March 2020, 03:22:04 UTC Fix the name of the first WAL segment file, in docs. Previously the documentation explains that WAL segment files start at 000000010000000000000000. But the first WAL segment file that initdb creates is 000000010000000000000001 not 000000010000000000000000. This change was caused by old commit 8c843fff2d, but the documentation had not been updated a long time. Back-patch to all supported branches. Author: Fujii Masao Reviewed-by: David Zhang Discussion: https://postgr.es/m/CAHGQGwHOmGe2OqGOmp8cOfNVDivq7dbV74L5nUGr+3eVd2CU2Q@mail.gmail.com 03 March 2020, 03:25:59 UTC
49300e4 Michael Paquier 27 February 2020, 02:21:28 UTC createdb: Fix quoting of --encoding, --lc-ctype and --lc-collate The original coding failed to properly quote those arguments, leading to failures when using quotes in the values used. As the quoting can be encoding-sensitive, the connection to the backend needs to be taken before applying the correct quoting. Author: Michael Paquier Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20200214041004.GB1998@paquier.xyz Backpatch-through: 9.5 27 February 2020, 02:21:28 UTC
bbefb11 Tom Lane 19 February 2020, 19:44:58 UTC Fix confusion about event trigger vs. plain function in plpgsql. The function hash table keys made by compute_function_hashkey() failed to distinguish event-trigger call context from regular call context. This meant that once we'd successfully made a hash entry for an event trigger (either by validation, or by normal use as an event trigger), an attempt to call the trigger function as a plain function would find this hash entry and thereby bypass the you-can't-do-that check in do_compile(). Thus we'd attempt to execute the function, leading to strange errors or even crashes, depending on function contents and server version. To fix, add an isEventTrigger field to PLpgSQL_func_hashkey, paralleling the longstanding infrastructure for regular triggers. This fits into what had been pad space, so there's no risk of an ABI break, even assuming that any third-party code is looking at these hash keys. (I considered replacing isTrigger with a PLpgSQL_trigtype enum field, but felt that that carried some API/ABI risk. Maybe we should change it in HEAD though.) Per bug #16266 from Alexander Lakhin. This has been broken since event triggers were invented, so back-patch to all supported branches. Discussion: https://postgr.es/m/16266-fcd7f838e97ba5d4@postgresql.org 19 February 2020, 19:44:58 UTC
4a3f164 Fujii Masao 19 February 2020, 11:37:26 UTC Fix mesurement of elapsed time during truncating heap in VACUUM. VACUUM may truncate heap in several batches. The activity report is logged for each batch, and contains the number of pages in the table before and after the truncation, and also the elapsed time during the truncation. Previously the elapsed time reported in each batch was the total elapsed time since starting the truncation until finishing each batch. For example, if the truncation was processed dividing into three batches, the second batch reported the accumulated time elapsed during both first and second batches. This is strange and confusing because the number of pages in the table reported together is not total. Instead, each batch should report the time elapsed during only that batch. The cause of this issue was that the resource usage snapshot was initialized only at the beginning of the truncation and was never reset later. This commit fixes the issue by changing VACUUM so that the resource usage snapshot is reset at each batch. Back-patch to all supported branches. Reported-by: Tatsuhito Kasahara Author: Tatsuhito Kasahara Reviewed-by: Masahiko Sawada, Fujii Masao Discussion: https://postgr.es/m/CAP0=ZVJsf=NvQuy+QXQZ7B=ZVLoDV_JzsVC1FRsF1G18i3zMGg@mail.gmail.com 19 February 2020, 11:43:59 UTC
05555f7 Amit Kapila 19 February 2020, 03:29:18 UTC Stop demanding that top xact must be seen before subxact in decoding. Manifested as ERROR: subtransaction logged without previous top-level txn record this check forbids legit behaviours like - First xl_xact_assignment record is beyond reading, i.e. earlier restart_lsn. - After restart_lsn there is some change of a subxact. - After that, there is second xl_xact_assignment (for another subxact) revealing the relationship between top and first subxact. Such a transaction won't be streamed anyway because we hadn't seen it in full. Saying for sure whether xact of some record encountered after the snapshot was deserialized can be streamed or not requires to know whether it wrote something before deserialization point --if yes, it hasn't been seen in full and can't be decoded. Snapshot doesn't have such info, so there is no easy way to relax the check. Reported-by: Hsu, John Diagnosed-by: Arseny Sher Author: Arseny Sher, Amit Kapila Reviewed-by: Amit Kapila, Dilip Kumar Backpatch-through: 9.5 Discussion: https://postgr.es/m/AB5978B2-1772-4FEE-A245-74C91704ECB0@amazon.com 19 February 2020, 03:29:18 UTC
d9ec8d1 Tom Lane 17 February 2020, 23:40:02 UTC Teach pg_dump to dump comments on RLS policy objects. This was unaccountably omitted in the original RLS patch. The SQL syntax is basically the same as for comments on triggers, so crib code from dumpTrigger(). Per report from Marc Munro. Back-patch to all supported branches. Discussion: https://postgr.es/m/1581889298.18009.15.camel@bloodnok.com 17 February 2020, 23:40:02 UTC
2b9d4ec Tom Lane 12 February 2020, 19:13:13 UTC Doc: fix old oversights in GRANT/REVOKE documentation. The GRANTED BY clause in GRANT/REVOKE ROLE has been there since 2005 but was never documented. I'm not sure now whether that was just an oversight or was intentional (given the limited capability of the option). But seeing that pg_dumpall does emit code that uses this option, it seems like not documenting it at all is a bad idea. Also, when we upgraded the syntax to allow CURRENT_USER/SESSION_USER as the privilege recipient, the role form of GRANT was incorrectly not modified to show that, and REVOKE's docs weren't touched at all. Although I'm not that excited about GRANTED BY, the other oversight seems serious enough to justify a back-patch. Discussion: https://postgr.es/m/3070.1581526786@sss.pgh.pa.us 12 February 2020, 19:13:13 UTC
221c6ba Peter Eisentraut 11 February 2020, 22:47:36 UTC Document the pg_upgrade -j/--jobs option as taking an argument 11 February 2020, 22:58:49 UTC
d9b89f1 Tom Lane 10 February 2020, 22:23:16 UTC Stamp 9.5.21. 10 February 2020, 22:23:16 UTC
4153ac0 Tom Lane 10 February 2020, 17:51:07 UTC Last-minute updates for release notes. Security: CVE-2020-1720 10 February 2020, 17:51:07 UTC
1b2ae4b Alvaro Herrera 10 February 2020, 15:14:58 UTC createuser: fix parsing of --connection-limit argument The original coding failed to quote the argument properly. Reported-by: Daniel Gustafsson Discussion: 1B8AE66C-85AB-4728-9BB4-612E8E61C219@yesql.se 10 February 2020, 15:16:40 UTC
a6e11f4 Peter Eisentraut 10 February 2020, 11:55:41 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: cde576a776a749a424b649f24259486752c7884d 10 February 2020, 11:55:41 UTC
ad70af1 Michael Paquier 10 February 2020, 06:48:56 UTC Revert "pg_upgrade: Fix quoting of some arguments in pg_ctl command" This reverts commit d1c0b61. The patch has some downsides that require more attention, as discussed with Noah Misch. Backpatch-through: 9.5 10 February 2020, 06:48:56 UTC
bd54e7a Michael Paquier 10 February 2020, 01:49:58 UTC pg_upgrade: Fix quoting of some arguments in pg_ctl command The previous coding forgot to apply shell quoting to the socket directory and the data folder, leading to failures when running pg_upgrade. This refactors the code generating the pg_ctl command starting clusters to use a more correct shell quoting. Failures are easier to trigger in 12 and newer versions by using a value of --socketdir that includes quotes, but it is also possible to cause failures with quotes included in the default socket directory used by pg_upgrade or the data folders of the clusters involved in the upgrade. As 9.4 is going to be EOL'd with the next minor release, nobody is likely going to upgrade to it now so this branch is not included in the set of branches fixed. Author: Michael Paquier Reviewed-by: Álvaro Herrera, Noah Misch Backpatch-through: 9.5 10 February 2020, 01:49:58 UTC
8be0a55 Tom Lane 09 February 2020, 19:14:19 UTC Release notes for 12.2, 11.7, 10.12, 9.6.17, 9.5.21, 9.4.26. 09 February 2020, 19:14:19 UTC
990acfc Fujii Masao 06 February 2020, 15:33:11 UTC Add note about access permission checks by inherited TRUNCATE and LOCK TABLE. Inherited queries perform access permission checks on the parent table only. But there are two exceptions to this rule in v12 or before; TRUNCATE and LOCK TABLE commands through a parent table check the permissions on not only the parent table but also the children tables. Previously these exceptions were not documented. This commit adds the note about these exceptions, into the document. Back-patch to v9.4. But we don't apply this commit to the master because commit e6f1e560e4 already got rid of the exception about inherited TRUNCATE and upcoming commit will do for the exception about inherited LOCK TABLE. Author: Amit Langote Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CA+HiwqHfTnMU6SUkyHxCmpHUKk7ERLHCR3vZVq19ZOQBjPBLmQ@mail.gmail.com 06 February 2020, 15:43:13 UTC
dc06d08 Fujii Masao 03 February 2020, 03:43:51 UTC Revert commit 606f350de9. This commit reverts the fix "Make inherited TRUNCATE perform access permission checks on parent table only" only in the back branches. It's not hard to imagine that there are some applications expecting the old behavior and the fix breaks their security. To avoid this compatibility problem, we decided to apply the fix only in HEAD and revert it in all supported back branches. Discussion: https://postgr.es/m/21015.1580400165@sss.pgh.pa.us 03 February 2020, 03:43:51 UTC
a5f45c3 Thomas Munro 01 February 2020, 01:29:13 UTC Fix memory leak on DSM slot exhaustion. If we attempt to create a DSM segment when no slots are available, we should return the memory to the operating system. Previously we did that if the DSM_CREATE_NULL_IF_MAXSEGMENTS flag was passed in, but we didn't do it if an error was raised. Repair. Back-patch to 9.4, where DSM segments arrived. Author: Thomas Munro Reviewed-by: Robert Haas Reported-by: Julian Backes Discussion: https://postgr.es/m/CA%2BhUKGKAAoEw-R4om0d2YM4eqT1eGEi6%3DQot-3ceDR-SLiWVDw%40mail.gmail.com 01 February 2020, 01:59:58 UTC
59047b6 Tom Lane 31 January 2020, 22:03:55 UTC Fix CheckAttributeType's handling of collations for ranges. Commit fc7695891 changed CheckAttributeType to recurse into ranges, but made it pass down the wrong collation (always InvalidOid, since ranges as such have no collation). This would result in guaranteed failure when considering a range type whose subtype is collatable. Embarrassingly, we lack any regression tests that would expose such a problem (but fortunately, somebody noticed before we shipped this bug in any release). Fix it to pass down the range's subtype collation property instead, and add some regression test cases to exercise collatable-subtype ranges a bit more. Back-patch to all supported branches, as the previous patch was. Report and patch by Julien Rouhaud, test cases tweaked by me Discussion: https://postgr.es/m/CAOBaU_aBWqNweiGUFX0guzBKkcfJ8mnnyyGC_KBQmO12Mj5f_A@mail.gmail.com 31 January 2020, 22:03:55 UTC
1b78759 Tom Lane 31 January 2020, 19:41:49 UTC Fix parallel pg_dump/pg_restore for failure to create worker processes. If we failed to fork a worker process, or create a communication pipe for one, WaitForTerminatingWorkers would suffer an assertion failure if assert-enabled, otherwise crash or go into an infinite loop. This was a consequence of not accounting for the startup condition where we've not yet forked all the workers. The original bug was that ParallelBackupStart would set workerStatus to WRKR_IDLE before it had successfully forked a worker. I made things worse in commit b7b8cc0cf by not understanding the undocumented fact that the WRKR_TERMINATED state was also meant to represent the case where a worker hadn't been started yet: I changed enum T_WorkerStatus so that *all* the worker slots were initially in WRKR_IDLE state. But this wasn't any more broken in practice, since even one slot in the wrong state would keep WaitForTerminatingWorkers from terminating. In v10 and later, introduce an explicit T_WorkerStatus value for worker-not-started, in hopes of preventing future oversights of the same ilk. Before that, just document that WRKR_TERMINATED is supposed to cover that case (partly because it wasn't actively broken, and partly because the enum is exposed outside parallel.c in those branches, so there's microscopically more risk involved in changing it). In all branches, introduce a WORKER_IS_RUNNING status test macro to hide which T_WorkerStatus values mean that, and be more careful not to access ParallelSlot fields till we're sure they're valid. Per report from Vignesh C, though this is my patch not his. Back-patch to all supported branches. Discussion: https://postgr.es/m/CALDaNm1Luv-E3sarR+-unz-BjchquHHyfP+YC+2FS2pt_J+wxg@mail.gmail.com 31 January 2020, 19:41:49 UTC
606f350 Fujii Masao 30 January 2020, 15:46:20 UTC Make inherited TRUNCATE perform access permission checks on parent table only. Previously, TRUNCATE command through a parent table checked the permissions on not only the parent table but also the children tables inherited from it. This was a bug and inherited queries should perform access permission checks on the parent table only. This commit fixes that bug. Back-patch to all supported branches. Author: Amit Langote Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CAHGQGwFHdSvifhJE+-GSNqUHSfbiKxaeQQ7HGcYz6SC2n_oDcg@mail.gmail.com 30 January 2020, 15:46:20 UTC
0e63d96 Tom Lane 23 January 2020, 21:15:32 UTC Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. 23 January 2020, 21:15:32 UTC
a576f2a Tom Lane 23 January 2020, 18:42:10 UTC Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/29432.1579731087@sss.pgh.pa.us 23 January 2020, 18:42:10 UTC
c39f455 Michael Paquier 22 January 2020, 00:49:44 UTC Fix concurrent indexing operations with temporary tables Attempting to use CREATE INDEX, DROP INDEX or REINDEX with CONCURRENTLY on a temporary relation with ON COMMIT actions triggered unexpected errors because those operations use multiple transactions internally to complete their work. Here is for example one confusing error when using ON COMMIT DELETE ROWS: ERROR: index "foo" already contains data Issues related to temporary relations and concurrent indexing are fixed in this commit by enforcing the non-concurrent path to be taken for temporary relations even if using CONCURRENTLY, transparently to the user. Using a non-concurrent path does not matter in practice as locks cannot be taken on a temporary relation by a session different than the one owning the relation, and the non-concurrent operation is more effective. The problem exists with REINDEX since v12 with the introduction of CONCURRENTLY, and with CREATE/DROP INDEX since CONCURRENTLY exists for those commands. In all supported versions, this caused only confusing error messages to be generated. Note that with REINDEX, it was also possible to issue a REINDEX CONCURRENTLY for a temporary relation owned by a different session, leading to a server crash. The idea to enforce transparently the non-concurrent code path for temporary relations comes originally from Andres Freund. Reported-by: Manuel Rigger Author: Michael Paquier, Heikki Linnakangas Reviewed-by: Andres Freund, Álvaro Herrera, Heikki Linnakangas Discussion: https://postgr.es/m/CA+u7OA6gP7YAeCguyseusYcc=uR8+ypjCcgDDCTzjQ+k6S9ksQ@mail.gmail.com Backpatch-through: 9.4 22 January 2020, 00:49:44 UTC
f651976 Andres Freund 21 January 2020, 07:26:51 UTC Fix edge case leading to agg transitions skipping ExecAggTransReparent() calls. The code checking whether an aggregate transition value needs to be reparented into the current context has always only compared the transition return value with the previous transition value by datum, i.e. without regard for NULLness. This normally works, because when the transition function returns NULL (via fcinfo->isnull), it'll return a value that won't be the same as its input value. But there's no hard requirement that that's the case. And it turns out, it's possible to hit this case (see discussion or reproducers), leading to a non-null transition value not being reparented, followed by a crash caused by that. Instead of adding another comparison of NULLness, instead have ExecAggTransReparent() ensure that pergroup->transValue ends up as 0 when the new transition value is NULL. That avoids having to add an additional branch to the much more common cases of the transition function returning the old transition value (which is a pointer in this case), and when the new value is different, but not NULL. In branches since 69c3936a149, also deduplicate the reparenting code between the expression evaluation based transitions, and the path for ordered aggregates. Reported-By: Teodor Sigaev, Nikita Glukhov Author: Andres Freund Discussion: https://postgr.es/m/bd34e930-cfec-ea9b-3827-a8bc50891393@sigaev.ru Backpatch: 9.4-, this issue has existed since at least 7.4 21 January 2020, 07:31:52 UTC
4a49149 Michael Paquier 21 January 2020, 04:47:13 UTC Add GUC variables for stat tracking and timeout as PGDLLIMPORT This helps integration of extensions with Windows. The following parameters are changed: - idle_in_transaction_session_timeout (9.6 and newer versions) - lock_timeout - statement_timeout - track_activities - track_counts - track_functions Author: Pascal Legrand Reviewed-by: Amit Kamila, Julien Rouhaud, Michael Paquier Discussion: https://postgr.es/m/1579298868581-0.post@n3.nabble.com Backpatch-through: 9.4 21 January 2020, 04:47:13 UTC
b1392a9 Tom Lane 20 January 2020, 17:57:17 UTC Fix pg_dump's sigTermHandler() to use _exit() not exit(). sigTermHandler() tried to be careful to invoke only operations that are safe to do in a signal handler. But for some reason we forgot that exit(3) is not among those, because it calls atexit handlers that might do various random things. (pg_dump itself installs no atexit handlers, but e.g. OpenSSL does.) That led to crashes or lockups when attempting to terminate a parallel dump or restore via a signal. Fix by calling _exit() instead. Per bug #16199 from Raúl Marín. Back-patch to all supported branches. Discussion: https://postgr.es/m/16199-cb2f121146a96f9b@postgresql.org 20 January 2020, 17:57:17 UTC
98f0d28 Heikki Linnakangas 20 January 2020, 08:36:35 UTC Fix crash in BRIN inclusion op functions, due to missing datum copy. The BRIN add_value() and union() functions need to make a longer-lived copy of the argument, if they want to store it in the BrinValues struct also passed as argument. The functions for the "inclusion operator classes" used with box, range and inet types didn't take into account that the union helper function might return its argument as is, without making a copy. Check for that case, and make a copy if necessary. That case arises at least with the range_union() function, when one of the arguments is an 'empty' range: CREATE TABLE brintest (n numrange); CREATE INDEX brinidx ON brintest USING brin (n); INSERT INTO brintest VALUES ('empty'); INSERT INTO brintest VALUES (numrange(0, 2^1000::numeric)); INSERT INTO brintest VALUES ('(-1, 0)'); SELECT brin_desummarize_range('brinidx', 0); SELECT brin_summarize_range('brinidx', 0); Backpatch down to 9.5, where BRIN was introduced. Discussion: https://www.postgresql.org/message-id/e6e1d6eb-0a67-36aa-e779-bcca59167c14%40iki.fi Reviewed-by: Emre Hasegeli, Tom Lane, Alvaro Herrera 20 January 2020, 08:36:55 UTC
3964722 Tom Lane 17 January 2020, 21:17:18 UTC Repair more failures with SubPlans in multi-row VALUES lists. Commit 9b63c13f0 turns out to have been fundamentally misguided: the parent node's subPlan list is by no means the only way in which a child SubPlan node can be hooked into the outer execution state. As shown in bug #16213 from Matt Jibson, we can also get short-lived tuple table slots added to the outer es_tupleTable list. At this point I have little faith that there aren't other possible connections as well; the long time it took to notice this problem shows that this isn't a heavily-exercised situation. Therefore, revert that fix, returning to the coding that passed a NULL parent plan pointer down to the transiently-built subexpressions. That gives us a pretty good guarantee that they won't hook into the outer executor state in any way. But then we need some other solution to make SubPlans work. Adopt the solution speculated about in the previous commit's log message: do expression initialization at plan startup for just those VALUES rows containing SubPlans, abandoning the goal of reclaiming memory intra-query for those rows. In practice it seems unlikely that queries containing a vast number of VALUES rows would be using SubPlans in them, so this should not give up much. (BTW, this test case also refutes my claim in connection with the prior commit that the issue only arises with use of LATERAL. That was just wrong: some variants of SubLink always produce SubPlans.) As with previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/16213-871ac3bc208ecf23@postgresql.org 17 January 2020, 21:17:37 UTC
58997ac Alvaro Herrera 17 January 2020, 21:00:39 UTC Set ReorderBufferTXN->final_lsn more eagerly ... specifically, set it incrementally as each individual change is spilled down to disk. This way, it is set correctly when the transaction disappears without trace, ie. without leaving an XACT_ABORT wal record. (This happens when the server crashes midway through a transaction.) Failing to have final_lsn prevents ReorderBufferRestoreCleanup() from working, since it needs the final_lsn in order to know the endpoint of its iteration through spilled files. Commit df9f682c7bf8 already tried to fix the problem, but it didn't set the final_lsn in all cases. Revert that, since it's no longer needed. Author: Vignesh C Reviewed-by: Amit Kapila, Dilip Kumar Discussion: https://postgr.es/m/CALDaNm2CLk+K9JDwjYST0sPbGg5AQdvhUt0jbKyX_HdAE0jk3A@mail.gmail.com 17 January 2020, 21:00:39 UTC
back to top