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
0e9cc8c Tom Lane 09 May 2022, 21:14:45 UTC Stamp 14.3. 09 May 2022, 21:14:45 UTC
0ae1d09 Tom Lane 09 May 2022, 18:29:53 UTC Last-minute updates for release notes. Security: CVE-2022-1552 09 May 2022, 18:29:53 UTC
ab2f783 Tom Lane 09 May 2022, 18:15:37 UTC Fix core dump in transformValuesClause when there are no columns. The parser code that transformed VALUES from row-oriented to column-oriented lists failed if there were zero columns. You can't write that straightforwardly (though probably you should be able to), but the case can be reached by expanding a "tab.*" reference to a zero-column table. Per bug #17477 from Wang Ke. Back-patch to all supported branches. Discussion: https://postgr.es/m/17477-0af3c6ac6b0a6ae0@postgresql.org 09 May 2022, 18:15:37 UTC
9b5797c Tom Lane 09 May 2022, 15:02:36 UTC Revert "Disallow infinite endpoints in generate_series() for timestamps." This reverts commit eafdf9de06e9b60168f5e47cedcfceecdc6d4b5f and its back-branch counterparts. Corey Huinker pointed out that we'd discussed this exact change back in 2016 and rejected it, on the grounds that there's at least one usage pattern with LIMIT where an infinite endpoint can usefully be used. Perhaps that argument needs to be re-litigated, but there's no time left before our back-branch releases. To keep our options open, restore the status quo ante; if we do end up deciding to change things, waiting one more quarter won't hurt anything. Rather than just doing a straight revert, I added a new test case demonstrating the usage with LIMIT. That'll at least remind us of the issue if we forget again. Discussion: https://postgr.es/m/3603504.1652068977@sss.pgh.pa.us Discussion: https://postgr.es/m/CADkLM=dzw0Pvdqp5yWKxMd+VmNkAMhG=4ku7GnCZxebWnzmz3Q@mail.gmail.com 09 May 2022, 15:40:40 UTC
677a494 Noah Misch 09 May 2022, 15:35:08 UTC In REFRESH MATERIALIZED VIEW, set user ID before running user code. It intended to, but did not, achieve this. Adopt the new standard of setting user ID just after locking the relation. Back-patch to v10 (all supported versions). Reviewed by Simon Riggs. Reported by Alvaro Herrera. Security: CVE-2022-1552 09 May 2022, 15:35:12 UTC
ab49ce7 Noah Misch 09 May 2022, 15:35:08 UTC Make relation-enumerating operations be security-restricted operations. When a feature enumerates relations and runs functions associated with all found relations, the feature's user shall not need to trust every user having permission to create objects. BRIN-specific functionality in autovacuum neglected to account for this, as did pg_amcheck and CLUSTER. An attacker having permission to create non-temp objects in at least one schema could execute arbitrary SQL functions under the identity of the bootstrap superuser. CREATE INDEX (not a relation-enumerating operation) and REINDEX protected themselves too late. This change extends to the non-enumerating amcheck interface. Back-patch to v10 (all supported versions). Sergey Shinderuk, reviewed (in earlier versions) by Alexander Lakhin. Reported by Alexander Lakhin. Security: CVE-2022-1552 09 May 2022, 15:35:12 UTC
e5b5a21 Peter Eisentraut 09 May 2022, 10:26:57 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: b7586f1542a8ffdfd1416e425f55e4e89c9a9505 09 May 2022, 10:26:57 UTC
55e5a5e Andres Freund 09 May 2022, 00:59:30 UTC Disable 031_recovery_conflict.pl until after minor releases. f40d362a667 disabled part of 031_recovery_conflict.pl due to instability that's not trivial to fix in the back branches. That fixed most of the issues. But there was one more failure (on lapwing / REL_10_STABLE). That failure looks like it might be caused by a genuine problem. Disable the test until after the set of releases, to avoid packagers etc potentially having to fight with a test failure they can't do anything about. Discussion: https://postgr.es/m/3447060.1652032749@sss.pgh.pa.us Backpatch: 10-14 09 May 2022, 01:06:19 UTC
2867d9b Tom Lane 08 May 2022, 16:36:38 UTC Release notes for 14.3, 13.7, 12.11, 11.16, 10.21. 08 May 2022, 16:36:38 UTC
e599ea0 Noah Misch 07 May 2022, 16:12:56 UTC Fix back-patch of "Under has_wal_read_bug, skip .../001_wal.pl." Per buildfarm members tadarida, snapper, and kittiwake. Back-patch to v10 (all supported versions). 07 May 2022, 16:12:56 UTC
aca4d56 Noah Misch 07 May 2022, 07:33:15 UTC Under has_wal_read_bug, skip contrib/bloom/t/001_wal.pl. Per buildfarm members snapper and kittiwake. Back-patch to v10 (all supported versions). Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com 07 May 2022, 07:38:40 UTC
f40d362 Andres Freund 06 May 2022, 16:01:08 UTC Temporarily skip recovery deadlock test in back branches. The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1) adjust_conf() doesn't exist, which is easy enough to work around 2) a restart cleares the recovery conflict stats < 15. These issues can be worked around, but given the upcoming set of minor releases, skip the problematic test for now. The buildfarm doesn't show failures in other parts of 031_recovery_conflict.pl. Discussion: https://postgr.es/m/20220506155827.dfnaheq6ufylwrqf@alap3.anarazel.de Backpatch: 10-14 06 May 2022, 16:01:08 UTC
7fa95bb Andres Freund 06 May 2022, 15:38:19 UTC Backpatch addition of pump_until() more completely. In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without changing the existing local definitions (as 6da65a3f9a9). The necessary changes seemed more verbose than desirable. However, that leads to warnings, as I failed to realize... Backpatch to all versions containing pump_until() calls before f74496dd611 (there's none in 10). Discussion: https://postgr.es/m/2808491.1651802860@sss.pgh.pa.us Discussion: https://postgr.es/m/18b37361-b482-b9d8-f30d-6115cd5ce25c@enterprisedb.com Backpatch: 11-14 06 May 2022, 15:38:19 UTC
66ca142 Tom Lane 05 May 2022, 22:27:31 UTC First-draft release notes for 14.3. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. 05 May 2022, 22:27:31 UTC
77ee14e Tom Lane 05 May 2022, 18:54:53 UTC Update time zone data files to tzdata release 2022a. DST law changes in Palestine. Historical corrections for Chile and Ukraine. 05 May 2022, 18:55:03 UTC
6e2924b Andres Freund 04 May 2022, 21:20:24 UTC Revert "Fix timing issue in deadlock recovery conflict test." This reverts commit 5136967f1eb194bf7598668f9893b997199935c1. 04 May 2022, 21:20:24 UTC
5136967 Andres Freund 04 May 2022, 19:50:38 UTC Fix timing issue in deadlock recovery conflict test. Per buildfarm members longfin and skink. Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de Backpatch: 10- 04 May 2022, 19:57:15 UTC
f74496d Andres Freund 03 May 2022, 01:26:09 UTC Backpatch 031_recovery_conflict.pl. The prior commit showed that the introduction of recovery conflict tests was a good idea. Without these tests it's hard to know that the fix didn't break something... 031_recovery_conflict.pl was introduced in 9f8a050f68d and extended in 21e184403bf. Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de Backpatch: 10-14 03 May 2022, 01:26:09 UTC
9ab3b2b Andres Freund 03 May 2022, 01:25:00 UTC Fix possibility of self-deadlock in ResolveRecoveryConflictWithBufferPin(). The tests added in 9f8a050f68d failed nearly reliably on FreeBSD in CI, and occasionally on the buildfarm. That turns out to be caused not by a bug in the test, but by a longstanding bug in recovery conflict handling. The standby timeout handler, used by ResolveRecoveryConflictWithBufferPin(), executed SendRecoveryConflictWithBufferPin() inside a signal handler. A bad idea, because the deadlock timeout handler (or a spurious latch set) could have interrupted ProcWaitForSignal(). If unlucky that could cause a self-deadlock on ProcArrayLock, if the deadlock check is in SendRecoveryConflictWithBufferPin()->CancelDBBackends(). To fix, set a flag in StandbyTimeoutHandler(), and check the flag in ResolveRecoveryConflictWithBufferPin(). Subsequently the recovery conflict tests will be backpatched. Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de Backpatch: 10- 03 May 2022, 01:25:59 UTC
5ab8e80 Andres Freund 03 May 2022, 01:09:42 UTC Backpatch addition of wait_for_log(), pump_until(). These were originally introduced in a2ab9c06ea1 and a2ab9c06ea1, as they are needed by a about-to-be-backpatched test. Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de Backpatch: 10-14 03 May 2022, 01:09:42 UTC
24c58f7 Etsuro Fujita 02 May 2022, 07:45:02 UTC Fix typo in comment. 02 May 2022, 07:45:02 UTC
ebb7902 Etsuro Fujita 28 April 2022, 06:15:02 UTC Disable asynchronous execution if using gating Result nodes. mark_async_capable_plan(), which is called from create_append_plan() to determine whether subplans are async-capable, failed to take into account that the given subplan created from a given subpath might include a gating Result node if the subpath is a SubqueryScanPath or ForeignPath, causing a segmentation fault there when the subplan created from a SubqueryScanPath includes the Result node, or causing ExecAsyncRequest() to throw an error about an unrecognized node type when the subplan created from a ForeignPath includes the Result node, because in the latter case the Result node was unintentionally considered as async-capable, but we don't currently support executing Result nodes asynchronously. Fix by modifying mark_async_capable_plan() to disable asynchronous execution in such cases. Also, adjust code in the ProjectionPath case in mark_async_capable_plan(), for consistency with other cases, and adjust/improve comments there. is_async_capable_path() added in commit 27e1f1456, which was rewritten to mark_async_capable_plan() in a later commit, has the same issue, causing the error at execution mentioned above, so back-patch to v14 where the aforesaid commit went in. Per report from Justin Pryzby. Etsuro Fujita, reviewed by Zhihong Yu and Justin Pryzby. Discussion: https://postgr.es/m/20220408124338.GK24419%40telsasoft.com 28 April 2022, 06:15:02 UTC
71f3946 Andrew Dunstan 25 April 2022, 19:02:13 UTC Inhibit mingw CRT's auto-globbing of command line arguments For some reason by default the mingw C Runtime takes it upon itself to expand program arguments that look like shell globbing characters. That has caused much scratching of heads and mis-attribution of the causes of some TAP test failures, so stop doing that. This removes an inconsistency with Windows binaries built with MSVC, which have no such behaviour. Per suggestion from Noah Misch. Backpatch to all live branches. Discussion: https://postgr.es/m/20220423025927.GA1274057@rfd.leadboat.com 25 April 2022, 19:49:35 UTC
75a006b Robert Haas 25 April 2022, 13:14:19 UTC Remove some recently-added pg_dump test cases. Commit d2d35479796c3510e249d6fc72adbd5df918efbf included a pretty extensive set of test cases, and some of them don't work on all of our Windows machines. This happens because IPC::Run expands its arguments as shell globs on a few machines, but doesn't on most of the buildfarm. It might be good to fix that problem systematically somehow, but in the meantime, there are enough test cases for this commit that it seems OK to just remove the ones that are failing. Discussion: http://postgr.es/m/3a190754-b2b0-d02b-dcfd-4ec1610ffbcb@dunslane.net Discussion: http://postgr.es/m/CA+TgmoYRGUcFBy6VgN0+Pn4f6Wv=2H0HZLuPHqSy6VC8Ba7vdg@mail.gmail.com 25 April 2022, 13:14:19 UTC
dff6c77 Tom Lane 23 April 2022, 16:16:12 UTC Fix incautious CTE matching in rewriteSearchAndCycle(). This function looks for a reference to the recursive WITH CTE, but it checked only the CTE name not ctelevelsup, so that it could seize on a lower CTE that happened to have the same name. This would result in planner failures later, either weird errors such as "could not find attribute 2 in subquery targetlist", or crashes or assertion failures. The code also merely Assert'ed that it found a matching entry, which is not guaranteed at all by the parser. Per bugs #17320 and #17318 from Zhiyong Wu. Thanks to Kyotaro Horiguchi for investigation. Discussion: https://postgr.es/m/17320-70e37868182512ab@postgresql.org Discussion: https://postgr.es/m/17318-2eb65a3a611d2368@postgresql.org 23 April 2022, 16:16:12 UTC
da22ef3 Tom Lane 21 April 2022, 21:58:52 UTC Remove inadequate assertion check in CTE inlining. inline_cte() expected to find exactly as many references to the target CTE as its cterefcount indicates. While that should be accurate for the tree as emitted by the parser, there are some optimizations that occur upstream of here that could falsify it, notably removal of unused subquery output expressions. Trying to make the accounting 100% accurate seems expensive and doomed to future breakage. It's not really worth it, because all this code is protecting is downstream assumptions that every referenced CTE has a plan. Let's convert those assertions to regular test-and-elog just in case there's some actual problem, and then drop the failing assertion. Per report from Tomas Vondra (thanks also to Richard Guo for analysis). Back-patch to v12 where the faulty code came in. Discussion: https://postgr.es/m/29196a1e-ed47-c7ca-9be2-b1c636816183@enterprisedb.com 21 April 2022, 21:58:52 UTC
b235d41 Andrew Dunstan 21 April 2022, 11:39:25 UTC Support new perl module namespace in stable branches Commit b3b4d8e68a moved our perl test modules to a better namespace structure, but this has made life hard for people wishing to backpatch improvements in the TAP tests. Here we alleviate much of that difficulty by implementing the new module names on top of the old modules, mostly by using a little perl typeglob aliasing magic, so that we don't have a dual maintenance burden. This should work both for the case where a new test is backpatched and the case where a fix to an existing test that uses the new namespace is backpatched. Reviewed by Michael Paquier Per complaint from Andres Freund Discussion: https://postgr.es/m/20220418141530.nfxtkohefvwnzncl@alap3.anarazel.de Applied to branches 10 through 14 21 April 2022, 13:01:26 UTC
89d349b Etsuro Fujita 21 April 2022, 06:30:02 UTC postgres_fdw: Disable batch insert when BEFORE ROW INSERT triggers exist. Previously, we allowed this, but such triggers might query the table to insert into and act differently if the tuples that have already been processed and prepared for insertion are not there, so disable it in such cases. Back-patch to v14 where batch insert was added. Discussion: https://postgr.es/m/CAPmGK16_uPqsmgK0-LpLSUk54_BoK13bPrhxhfjSoSTVz414hA%40mail.gmail.com 21 April 2022, 06:30:02 UTC
e452184 Peter Geoghegan 21 April 2022, 00:17:41 UTC Fix CLUSTER tuplesorts on abbreviated expressions. CLUSTER sort won't use the datum1 SortTuple field when clustering against an index whose leading key is an expression. This makes it unsafe to use the abbreviated keys optimization, which was missed by the logic that sets up SortSupport state. Affected tuplesorts output tuples in a completely bogus order as a result (the wrong SortSupport based comparator was used for the leading attribute). This issue is similar to the bug fixed on the master branch by recent commit cc58eecc5d. But it's a far older issue, that dates back to the introduction of the abbreviated keys optimization by commit 4ea51cdfe8. Backpatch to all supported versions. Author: Peter Geoghegan <pg@bowt.ie> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CA+hUKG+bA+bmwD36_oDxAoLrCwZjVtST2fqe=b4=qZcmU7u89A@mail.gmail.com Backpatch: 10- 21 April 2022, 00:17:41 UTC
e346329 Tom Lane 20 April 2022, 22:08:15 UTC Disallow infinite endpoints in generate_series() for timestamps. Such cases will lead to infinite loops, so they're of no practical value. The numeric variant of generate_series() already threw error for this, so borrow its message wording. Per report from Richard Wesley. Back-patch to all supported branches. Discussion: https://postgr.es/m/91B44E7B-68D5-448F-95C8-B4B3B0F5DEAF@duckdblabs.com 20 April 2022, 22:08:24 UTC
4a66300 Robert Haas 20 April 2022, 15:02:35 UTC Allow db.schema.table patterns, but complain about random garbage. psql, pg_dump, and pg_amcheck share code to process object name patterns like 'foo*.bar*' to match all tables with names starting in 'bar' that are in schemas starting with 'foo'. Before v14, any number of extra name parts were silently ignored, so a command line '\d foo.bar.baz.bletch.quux' was interpreted as '\d bletch.quux'. In v14, as a result of commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868, we instead treated this as a request for table quux in a schema named 'foo.bar.baz.bletch'. That caused problems for people like Justin Pryzby who were accustomed to copying strings of the form db.schema.table from messages generated by PostgreSQL itself and using them as arguments to \d. Accordingly, revise things so that if an object name pattern contains more parts than we're expecting, we throw an error, unless there's exactly one extra part and it matches the current database name. That way, thisdb.myschema.mytable is accepted as meaning just myschema.mytable, but otherdb.myschema.mytable is an error, and so is some.random.garbage.myschema.mytable. Mark Dilger, per report from Justin Pryzby and discussion among various people. Discussion: https://www.postgresql.org/message-id/20211013165426.GD27491%40telsasoft.com 20 April 2022, 15:39:44 UTC
7891a0d Amit Kapila 20 April 2022, 03:18:25 UTC Stabilize streaming tests in test_decoding. We have some streaming tests that rely on the size of changes which can fail if there are additional changes like invalidation messages by background activity like auto analyze. Avoid such failures by increasing autovacuum_naptime to a reasonably high value (1d). Author: Dilip Kumar Backpatch-through: 14 Discussion: https://postgr.es/m/1958043.1650129119@sss.pgh.pa.us 20 April 2022, 03:18:25 UTC
08a9e7a Tom Lane 20 April 2022, 03:03:59 UTC Fix breakage in AlterFunction(). An ALTER FUNCTION command that tried to update both the function's proparallel property and its proconfig list failed to do the former, because it stored the new proparallel value into a tuple that was no longer the interesting one. Carelessness in 7aea8e4f2. (I did not bother with a regression test, because the only likely future breakage would be for someone to ignore the comment I added and add some other field update after the heap_modify_tuple step. A test using existing function properties could not catch that.) Per report from Bryn Llewellyn. Back-patch to all supported branches. Discussion: https://postgr.es/m/8AC9A37F-99BD-446F-A2F7-B89AD0022774@yugabyte.com 20 April 2022, 03:03:59 UTC
7a8d821 Peter Eisentraut 19 April 2022, 18:38:53 UTC Fix extract epoch from interval calculation The new numeric code for extract epoch from interval accidentally truncated the DAYS_PER_YEAR value to an integer, leading to results that mismatched the floating-point interval_part calculations. The commit a2da77cdb4661826482ebf2ddba1f953bc74afe4 that introduced this actually contains the regression test change that this reverts. I suppose this was missed at the time. Reported-by: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAAvxfHd5n%3D13NYA2q_tUq%3D3%3DSuWU-CufmTf-Ozj%3DfrEgt7pXwQ%40mail.gmail.com 19 April 2022, 19:03:27 UTC
c9dea58 Amit Kapila 19 April 2022, 03:24:37 UTC Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e797c8@enterprisedb.com 19 April 2022, 03:24:37 UTC
e805735 Tom Lane 18 April 2022, 16:16:45 UTC Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb5740d3@postgresql.org 18 April 2022, 16:16:45 UTC
8bcf90c Michael Paquier 18 April 2022, 02:40:14 UTC Fix race in TAP test 002_archiving.pl when restoring history file This test, introduced in df86e52, uses a second standby to check that it is able to remove correctly RECOVERYHISTORY and RECOVERYXLOG at the end of recovery. This standby uses the archives of the primary to restore its contents, with some of the archive's contents coming from the first standby previously promoted. In slow environments, it was possible that the test did not check what it should, as the history file generated by the promotion of the first standby may not be stored yet on the archives the second standby feeds on. So, it could be possible that the second standby selects an incorrect timeline, without restoring a history file at all. This commits adds a wait phase to make sure that the history file required by the second standby is archived before this cluster is created. This relies on poll_query_until() with pg_stat_file() and an absolute path, something not supported in REL_10_STABLE. While on it, this adds a new test to check that the history file has been restored by looking at the logs of the second standby. This ensures that a RECOVERYHISTORY, whose removal needs to be checked, is created in the first place. This should make the test more robust. This test has been introduced by df86e52, but it came in light as an effect of the bug fixed by acf1dd42, where the extra restore_command calls made the test much slower. Reported-by: Andres Freund Discussion: https://postgr.es/m/YlT23IvsXkGuLzFi@paquier.xyz Backpatch-through: 11 18 April 2022, 02:40:14 UTC
acd0eb6 Noah Misch 17 April 2022, 00:43:54 UTC Add a temp-install prerequisite to src/interfaces/ecpg "checktcp". The target failed, tested $PATH binaries, or tested a stale temporary installation. Commit c66b438db62748000700c9b90b585e756dd54141 missed this. Back-patch to v10 (all supported versions). 17 April 2022, 00:43:57 UTC
10520f4 Robert Haas 14 April 2022, 15:10:07 UTC Rethink the delay-checkpoint-end mechanism in the back-branches. The back-patch of commit bbace5697df12398e87ffd9879171c39d27f5b33 had the unfortunate effect of changing the layout of PGPROC in the back-branches, which could break extensions. This happened because it changed the delayChkpt from type bool to type int. So, change it back, and add a new bool delayChkptEnd field instead. The new field should fall within what used to be padding space within the struct, and so hopefully won't cause any extensions to break. Per report from Markus Wanner and discussion with Tom Lane and others. Patch originally by me, somewhat revised by Markus Wanner per a suggestion from Michael Paquier. A very similar patch was developed by Kyotaro Horiguchi, but I failed to see the email in which that was posted before writing one of my own. Discussion: http://postgr.es/m/CA+Tgmoao-kUD9c5nG5sub3F7tbo39+cdr8jKaOVEs_1aBWcJ3Q@mail.gmail.com Discussion: http://postgr.es/m/20220406.164521.17171257901083417.horikyota.ntt@gmail.com 14 April 2022, 15:10:07 UTC
df6bbe7 Michael Paquier 14 April 2022, 06:09:26 UTC pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru Backpatch-through: 10 14 April 2022, 06:09:26 UTC
c590e51 Tom Lane 13 April 2022, 17:35:02 UTC Prevent access to no-longer-pinned buffer in heapam_tuple_lock(). heap_fetch() used to have a "keep_buf" parameter that told it to return ownership of the buffer pin to the caller after finding that the requested tuple TID exists but is invisible to the specified snapshot. This was thoughtlessly removed in commit 5db6df0c0, which broke heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function needs to do more accesses to the tuple even if it's invisible. The net effect is that we would continue to touch the page for a microsecond or two after releasing pin on the buffer. Usually no harm would result; but if a different session decided to defragment the page concurrently, we could see garbage data and mistakenly conclude that there's no newer tuple version to chain up to. (It's hard to say whether this has happened in the field. The bug was actually found thanks to a later change that allowed valgrind to detect accesses to non-pinned buffers.) The most reasonable way to fix this is to reintroduce keep_buf, although I made it behave slightly differently: buffer ownership is passed back only if there is a valid tuple at the requested TID. In HEAD, we can just add the parameter back to heap_fetch(). To avoid an API break in the back branches, introduce an additional function heap_fetch_extended() in those branches. In HEAD there is an additional, less obvious API change: tuple->t_data will be set to NULL in all cases where buffer ownership is not returned, in particular when the tuple exists but fails the time qual (and !keep_buf). This is to defend against any other callers attempting to access non-pinned buffers. We concluded that making that change in back branches would be more likely to introduce problems than cure any. In passing, remove a comment about heap_fetch that was obsoleted by 9a8ee1dc6. Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug was introduced. Discussion: https://postgr.es/m/17462-9c98a0f00df9bd36@postgresql.org 13 April 2022, 17:35:02 UTC
ea669b8 David Rowley 13 April 2022, 09:29:35 UTC Docs: wording improvement for compute_query_id = regress It's more accurate to say that the query identifier is not shown when compute_query_id = regress rather than to say it is hidden. This change (ebf6c5249) appeared in v14, so it makes sense to backpatch this small adjustment to keep the documents consistent between v14 and master. Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com Backpatch-through: 14, where compute_query_id = regress was added 13 April 2022, 09:29:35 UTC
e286be5 David Rowley 12 April 2022, 23:19:34 UTC Docs: adjust pg_upgrade syntax to mark -B as optional This was made optional in 959f6d6a1. Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com Backpatch-through: 13, where -B was made optional 12 April 2022, 23:19:34 UTC
8320a34 Tom Lane 12 April 2022, 22:21:04 UTC Doc: tweak textsearch.sgml for SEO purposes. Google seems to like to return textsearch.html for queries about GIN and GiST indexes, even though it's not a primary reference for either. It seems likely that that's because those keywords appear in the page title. Since "GIN and GiST Index Types" is not a very apposite title for this material anyway, rename the section in hopes of stopping that. Also provide explicit links to the GIN and GiST chapters, to help anyone who finds their way to this page regardless. Per gripe from Jan Piotrowski. Back-patch to supported branches. (Unfortunately Google is likely to continue returning the 9.1 version of this page, but improving that situation is a matter for the www team.) Discussion: https://postgr.es/m/164978902252.1276550.9330175733459697101@wrigleys.postgresql.org 12 April 2022, 22:21:17 UTC
3a95dfe David Rowley 12 April 2022, 21:16:33 UTC Docs: avoid confusing use of the word "synchronized" It's misleading to call the data directory the "synchronized data directory" when discussing a crash scenario when using pg_rewind's --no-sync option. Here we just remove the word "synchronized" to avoid any possible confusion. Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com Backpatch-through: 12, where --no-sync was added 12 April 2022, 21:16:33 UTC
a65747b Tom Lane 06 April 2022, 21:03:35 UTC Suppress "variable 'pagesaving' set but not used" warning. With asserts disabled, late-model clang notices that this variable is incremented but never otherwise read. Discussion: https://postgr.es/m/3171401.1649275153@sss.pgh.pa.us 06 April 2022, 21:03:35 UTC
9a72299 Tom Lane 06 April 2022, 00:44:01 UTC Remove race condition in 022_crash_temp_files.pl test. It's possible for the query that "waits for restart" to complete a successful iteration before the postmaster has noticed its SIGKILL'd child and begun the restart cycle. (This is a bit hard to believe perhaps, but it's been seen at least twice in the buildfarm, mainly on ancient platforms that likely have quirky schedulers.) To provide a more secure interlock, wait for the other session we're using to report that it's been forcibly shut down. Patch by me, based on a suggestion from Andres Freund. Back-patch to v14 where this test case came in. Discussion: https://postgr.es/m/1801850.1649047827@sss.pgh.pa.us 06 April 2022, 00:44:01 UTC
8803df4 Tom Lane 05 April 2022, 02:10:07 UTC Update some tests in 013_crash_restart.pl. The expected backend message after SIGQUIT changed in commit 7e784d1dc, but we missed updating this test case. Also, experience shows that we might sometimes get "could not send data to server" instead of either of the libpq messages the test is looking for. Per report from Mark Dilger. Back-patch to v14 where the backend message changed. Discussion: https://postgr.es/m/17BD82D7-49AC-40C9-8204-E7ADD30321A0@enterprisedb.com 05 April 2022, 02:10:07 UTC
32558a8 Peter Geoghegan 02 April 2022, 16:49:06 UTC Doc: Remove MultiXact wraparound section link. Remove circular "25.1.5.1. Multixacts And Wraparound" link that references the section that the link itself appears in. An explanation of MultiXactId age appears only a few sentences before the link, so there's no question that the link is superfluous at best. Oversight in commit d5409295. Author: Peter Geoghegan <pg@bowt.ie> Backpatch: 14- 02 April 2022, 16:49:06 UTC
d480ae0 Peter Eisentraut 02 April 2022, 05:27:26 UTC Remove obsolete comment accidentally left behind by 4cb658af70027c3544fb843d77b2e84028762747 02 April 2022, 05:28:11 UTC
7a27892 Peter Eisentraut 01 April 2022, 15:12:56 UTC libpq: Fix pkg-config without OpenSSL Do not add OpenSSL dependencies to libpq pkg-config file if OpenSSL is not enabled. Oversight in beff361bc1edc24ee5f8b2073a1e5e4c92ea66eb. Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/20220331163759.32665-1-fontaine.fabrice%40gmail.com 01 April 2022, 15:12:56 UTC
9f9489a Tom Lane 31 March 2022, 18:29:24 UTC Fix postgres_fdw to check shippability of sort clauses properly. postgres_fdw would push ORDER BY clauses to the remote side without verifying that the sort operator is safe to ship. Moreover, it failed to print a suitable USING clause if the sort operator isn't default for the sort expression's type. The net result of this is that the remote sort might not have anywhere near the semantics we expect, which'd be disastrous for locally-performed merge joins in particular. We addressed similar issues in the context of ORDER BY within an aggregate function call in commit 7012b132d, but failed to notice that query-level ORDER BY was broken. Thus, much of the necessary logic already existed, but it requires refactoring to be usable in both cases. Back-patch to all supported branches. In HEAD only, remove the core code's copy of find_em_expr_for_rel, which is no longer used and really should never have been pushed into equivclass.c in the first place. Ronan Dunklau, per report from David Rowley; reviews by David Rowley, Ranier Vilela, and myself Discussion: https://postgr.es/m/CAApHDvr4OeC2DBVY--zVP83-K=bYrTD7F8SZDhN4g+pj2f2S-A@mail.gmail.com 31 March 2022, 18:29:24 UTC
402279a Tom Lane 31 March 2022, 15:24:26 UTC Add missing newline in one libpq error message. Oversight in commit a59c79564. Back-patch, as that was. Noted by Peter Eisentraut. Discussion: https://postgr.es/m/7f85ef6d-250b-f5ec-9867-89f0b16d019f@enterprisedb.com 31 March 2022, 15:24:26 UTC
c547917 Daniel Gustafsson 31 March 2022, 10:03:33 UTC doc: Fix typo in ANALYZE documentation Commit 61fa6ca79b3 accidentally wrote constrast instead of contrast. Backpatch-through: 10 Discussion: https://postgr.es/m/88903179-5ce2-3d4d-af43-7830372bdcb6@enterprisedb.com 31 March 2022, 10:03:33 UTC
637afee Etsuro Fujita 30 March 2022, 10:00:02 UTC Fix typo in comment. 30 March 2022, 10:00:02 UTC
adc943b Alvaro Herrera 29 March 2022, 13:36:21 UTC Revert "Fix replay of create database records on standby" This reverts commit 49d9cfc68bf4. The approach taken by this patch has problems, so we'll come up with a radically different fix. Discussion: https://postgr.es/m/CA+TgmoYcUPL+WOJL2ZzhH=zmrhj0iOQ=iCFM0SuYqBbqZEamEg@mail.gmail.com 29 March 2022, 13:36:21 UTC
6b262f3 Tomas Vondra 28 March 2022, 12:27:36 UTC Document autoanalyze limitations for partitioned tables When dealing with partitioned tables, counters for partitioned tables are not updated when modifying child tables. This means autoanalyze may not update optimizer statistics for the parent relations, which can result in poor plans for some queries. It's worth documenting this limitation, so that people are aware of it and can take steps to mitigate it (e.g. by setting up a script executing ANALYZE regularly). Backpatch to v10. Older branches are affected too, of couse, but we no longer maintain those. Author: Justin Pryzby Reviewed-by: Zhihong Yu, Tomas Vondra Backpatch-through: 10 Discussion: https://postgr.es/m/20210913035409.GA10647%40telsasoft.com 28 March 2022, 12:30:44 UTC
c1a0d7d Andres Freund 28 March 2022, 04:39:43 UTC Fix NULL input behaviour of pg_stat_get_replication_slot(). pg_stat_get_replication_slot() accidentally was marked as non-strict, crashing when called with NULL input. As it's already released, introduce an explicit NULL check in 14, fix the catalog in HEAD. Bumps catversion in HEAD. Discussion: https://postgr.es/m/20220326212432.s5n2maw6kugnpyxw@alap3.anarazel.de Backpatch: 14-, where replication slot stats were introduced 28 March 2022, 04:44:39 UTC
6839aa7 Andres Freund 23 March 2022, 23:38:43 UTC waldump: fix use-after-free in search_directory(). After closedir() dirent->d_name is not valid anymore. As there alerady are a few places relying on the limited lifetime of pg_waldump, do so here as well, and just pg_strdup() the string. The bug was introduced in fc49e24fa69a. Found by UBSan, run locally. Backpatch: 11-, like fc49e24fa69 itself. 28 March 2022, 01:15:10 UTC
3f7a59c Tom Lane 27 March 2022, 16:57:46 UTC Fix breakage of get_ps_display() in the PS_USE_NONE case. Commit 8c6d30f21 caused this function to fail to set *displen in the PS_USE_NONE code path. If the variable's previous value had been negative, that'd lead to a memory clobber at some call sites. We'd managed not to notice due to very thin test coverage of such configurations, but this appears to explain buildfarm member lorikeet's recent struggles. Credit to Andrew Dunstan for spotting the problem. Back-patch to v13 where the bug was introduced. Discussion: https://postgr.es/m/136102.1648320427@sss.pgh.pa.us 27 March 2022, 16:57:52 UTC
27d3844 Michael Paquier 27 March 2022, 08:53:51 UTC pageinspect: Add more sanity checks to prevent out-of-bound reads A couple of code paths use the special area on the page passed by the function caller, expecting to find some data in it. However, feeding an incorrect page can lead to out-of-bound reads when trying to access the page special area (like a heap page that has no special area, leading PageGetSpecialPointer() to grab a pointer outside the allocated page). The functions used for hash and btree indexes have some protection already against that, while some other functions using a relation OID as argument would make sure that the access method involved is correct, but functions taking in input a raw page without knowing the relation the page is attached to would run into problems. This commit improves the set of checks used in the code paths of BRIN, btree (including one check if a leaf page is found with a non-zero level), GIN and GiST to verify that the page given in input has a special area size that fits with each access method, which is done though PageGetSpecialSize(), becore calling PageGetSpecialPointer(). The scope of the checks done is limited to work with pages that one would pass after getting a block with get_raw_page(), as it is possible to craft byteas that could bypass existing code paths. Having too many checks would also impact the usability of pageinspect, as the existing code is very useful to look at the content details in a corrupted page, so the focus is really to avoid out-of-bound reads as this is never a good thing even with functions whose execution is limited to superusers. The safest approach could be to rework the functions so as these fetch a block using a relation OID and a block number, but there are also cases where using a raw page is useful. Tests are added to cover all the code paths that needed such checks, and an error message for hash indexes is reworded to fit better with what this commit adds. Reported-By: Alexander Lakhin Author: Julien Rouhaud, Michael Paquier Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru Backpatch-through: 10 27 March 2022, 08:53:51 UTC
0144c9c Tom Lane 26 March 2022, 18:29:29 UTC Suppress compiler warning in relptr_store(). clang 13 with -Wextra warns that "performing pointer subtraction with a null pointer has undefined behavior" in the places where freepage.c tries to set a relptr variable to constant NULL. This appears to be a compiler bug, but it's unlikely to get fixed instantly. Fortunately, we can work around it by introducing an inline support function, which seems like a good change anyway because it removes the macro's existing double-evaluation hazard. Backpatch to v10 where this code was introduced. Patch by me, based on an idea of Andres Freund's. Discussion: https://postgr.es/m/48826.1648310694@sss.pgh.pa.us 26 March 2022, 18:29:40 UTC
579cef5 Tom Lane 25 March 2022, 18:23:26 UTC Harden TAP tests that intentionally corrupt page checksums. The previous method for doing that was to write zeroes into a predetermined set of page locations. However, there's a roughly 1-in-64K chance that the existing checksum will match by chance, and yesterday several buildfarm animals started to reproducibly see that, resulting in test failures because no checksum mismatch was reported. Since the checksum includes the page LSN, test success depends on the length of the installation's WAL history, which is affected by (at least) the initial catalog contents, the set of locales installed on the system, and the length of the pathname of the test directory. Sooner or later we were going to hit a chance match, and today is that day. Harden these tests by specifically inverting the checksum field and leaving all else alone, thereby guaranteeing that the checksum is incorrect. In passing, fix places that were using seek() to set up for syswrite(), a combination that the Perl docs very explicitly warn against. We've probably escaped problems because no regular buffered I/O is done on these filehandles; but if it ever breaks, we wouldn't deserve or get much sympathy. Although we've only seen problems in HEAD, now that we recognize the environmental dependencies it seems like it might be just a matter of time until someone manages to hit this in back-branch testing. Hence, back-patch to v11 where we started doing this kind of test. Discussion: https://postgr.es/m/3192026.1648185780@sss.pgh.pa.us 25 March 2022, 18:23:26 UTC
ffd2851 Alvaro Herrera 25 March 2022, 12:16:21 UTC Fix replay of create database records on standby Crash recovery on standby may encounter missing directories when replaying create database WAL records. Prior to this patch, the standby would fail to recover in such a case. However, the directories could be legitimately missing. Consider a sequence of WAL records as follows: CREATE DATABASE DROP DATABASE DROP TABLESPACE If, after replaying the last WAL record and removing the tablespace directory, the standby crashes and has to replay the create database record again, the crash recovery must be able to move on. This patch adds a mechanism similar to invalid-page tracking, to keep a tally of missing directories during crash recovery. If all the missing directory references are matched with corresponding drop records at the end of crash recovery, the standby can safely continue following the primary. Backpatch to 13, at least for now. The bug is older, but fixing it in older branches requires more careful study of the interactions with commit e6d8069522c8, which appeared in 13. A new TAP test file is added to verify the condition. However, because it depends on commit d6d317dbf615, it can only be added to branch master. I (Álvaro) manually verified that the code behaves as expected in branch 14. It's a bit nervous-making to leave the code uncovered by tests in older branches, but leaving the bug unfixed is even worse. Also, the main reason this fix took so long is precisely that we couldn't agree on a good strategy to approach testing for the bug, so perhaps this is the best we can do. Diagnosed-by: Paul Guo <paulguo@gmail.com> Author: Paul Guo <paulguo@gmail.com> Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Asim R Praveen <apraveen@pivotal.io> Discussion: https://postgr.es/m/CAEET0ZGx9AvioViLf7nbR_8tH9-=27DN5xWJ2P9-ROH16e4JUA@mail.gmail.com 25 March 2022, 12:16:21 UTC
bbace56 Robert Haas 24 March 2022, 18:32:24 UTC Fix possible recovery trouble if TRUNCATE overlaps a checkpoint. If TRUNCATE causes some buffers to be invalidated and thus the checkpoint does not flush them, TRUNCATE must also ensure that the corresponding files are truncated on disk. Otherwise, a replay from the checkpoint might find that the buffers exist but have the wrong contents, which may cause replay to fail. Report by Teja Mupparti. Patch by Kyotaro Horiguchi, per a design suggestion from Heikki Linnakangas, with some changes to the comments by me. Review of this and a prior patch that approached the issue differently by Heikki Linnakangas, Andres Freund, Álvaro Herrera, Masahiko Sawada, and Tom Lane. Discussion: http://postgr.es/m/BYAPR06MB6373BF50B469CA393C614257ABF00@BYAPR06MB6373.namprd06.prod.outlook.com 24 March 2022, 18:32:48 UTC
81045e1 Andres Freund 23 March 2022, 20:05:59 UTC Don't try to translate NULL in GetConfigOptionByNum(). Noticed via -fsanitize=undefined. Introduced when a few columns in GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a / PG 12. Backpatch to all affected branches, for the same reasons as 46ab07ffda9. Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de Backpatch: 12- 23 March 2022, 20:18:02 UTC
89a94c2 Andres Freund 23 March 2022, 20:05:25 UTC Don't call fwrite() with len == 0 when writing out relcache init file. Noticed via -fsanitize=undefined. Backpatch to all branches, for the same reasons as 46ab07ffda9. Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de Backpatch: 10- 23 March 2022, 20:13:18 UTC
e52e9bd Andres Freund 23 March 2022, 19:43:14 UTC configure: check for dlsym instead of dlopen. When building with sanitizers the sanitizer library provides dlopen, but not dlsym(), making configure think that -ldl isn't needed. Just checking for dlsym() ought to suffice, hard to see dlsym() being provided without dlopen() also being provided. Backpatch to all branches, for the same reasons as 46ab07ffda9. Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de Backpatch: 10- 23 March 2022, 19:43:41 UTC
9814c70 Alvaro Herrera 23 March 2022, 18:23:51 UTC pg_upgrade: Upgrade an Assert to a real 'if' test It seems possible for the condition being tested to be true in production, and nobody would never know (except when some data eventually becomes corrupt?). Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre.pgsql 23 March 2022, 18:23:51 UTC
caaeb88 Alvaro Herrera 23 March 2022, 17:22:10 UTC Fix "missing continuation record" after standby promotion Invalidate abortedRecPtr and missingContrecPtr after a missing continuation record is successfully skipped on a standby. This fixes a PANIC caused when a recently promoted standby attempts to write an OVERWRITE_RECORD with an LSN of the previously read aborted record. Backpatch to 10 (all stable versions). Author: Sami Imseih <simseih@amazon.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/44D259DE-7542-49C4-8A52-2AB01534DCA9@amazon.com 23 March 2022, 17:22:10 UTC
cd3a505 Thomas Munro 23 March 2022, 01:31:18 UTC Try to stabilize vacuum test. As commits b700f96c and 3414099c did for the reloptions test, make sure VACUUM can always truncate the table as expected. Back-patch to 12, where vacuum_truncate arrived. Discussion: https://postgr.es/m/CAD21AoCNoWjYkdEtr%2BVDoF9v__V905AedKZ9iF%3DArgCtrbxZqw%40mail.gmail.com 23 March 2022, 02:06:59 UTC
2d608c9 Andres Freund 22 March 2022, 15:22:02 UTC Add missing dependency of pg_dumpall to WIN32RES. When cross-building to windows, or building with mingw on windows, the build could fail with x86_64-w64-mingw32-gcc: error: win32ver.o: No such file or director because pg_dumpall didn't depend on WIN32RES, but it's recipe references it. The build nevertheless succeeded most of the time, due to pg_dump/pg_restore having the required dependency, causing win32ver.o to be built. Reported-By: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CA+hUKGJeekpUPWW6yCVdf9=oBAcCp86RrBivo4Y4cwazAzGPng@mail.gmail.com Backpatch: 10-, omission present on all live branches 22 March 2022, 15:28:51 UTC
fdb1be4 Michael Paquier 22 March 2022, 04:21:33 UTC Fix failures in SSL tests caused by out-of-tree keys and certificates This issue is environment-sensitive, where the SSL tests could fail in various way by feeding on defaults provided by sslcert, sslkey, sslrootkey, sslrootcert, sslcrl and sslcrldir coming from a local setup, as of ~/.postgresql/ by default. Horiguchi-san has reported two failures, but more advanced testing from me (aka inclusion of garbage SSL configuration in ~/.postgresql/ for all the configuration parameters) has showed dozens of failures that can be triggered in the whole test suite. History has showed that we are not good when it comes to address such issues, fixing them locally like in dd87799, and such problems keep appearing. This commit strengthens the entire test suite to put an end to this set of problems by embedding invalid default values in all the connection strings used in the tests. The invalid values are prefixed in each connection string, relying on the follow-up values passed in the connection string to enforce any invalid value previously set. Note that two tests related to CRLs are required to fail with certain pre-set configurations, but we can rely on enforcing an empty value instead after the invalid set of values. Reported-by: Kyotaro Horiguchi Reviewed-by: Andrew Dunstan, Daniel Gustafsson, Kyotaro Horiguchi Discussion: https://postgr.es/m/20220316.163658.1122740600489097632.horikyota.ntt@gmail.com backpatch-through: 10 22 March 2022, 04:21:33 UTC
48b6035 Tom Lane 21 March 2022, 21:44:29 UTC Fix assorted missing logic for GroupingFunc nodes. The planner needs to treat GroupingFunc like Aggref for many purposes, in particular with respect to processing of the argument expressions, which are not to be evaluated at runtime. A few places hadn't gotten that memo, notably including subselect.c's processing of outer-level aggregates. This resulted in assertion failures or wrong plans for cases in which a GROUPING() construct references an outer aggregation level. Also fix missing special cases for GroupingFunc in cost_qual_eval (resulting in wrong cost estimates for GROUPING(), although it's not clear that that would affect plan shapes in practice) and in ruleutils.c (resulting in excess parentheses in pretty-print mode). Per bug #17088 from Yaoguang Chen. Back-patch to all supported branches. Richard Guo, Tom Lane Discussion: https://postgr.es/m/17088-e33882b387de7f5c@postgresql.org 21 March 2022, 21:44:29 UTC
05ccf97 Tom Lane 21 March 2022, 16:22:13 UTC Fix risk of deadlock failure while dropping a partitioned index. DROP INDEX needs to lock the index's table before the index itself, else it will deadlock against ordinary queries that acquire the relation locks in that order. This is correctly mechanized for plain indexes by RangeVarCallbackForDropRelation; but in the case of a partitioned index, we neglected to lock the child tables in advance of locking the child indexes. We can fix that by traversing the inheritance tree and acquiring the needed locks in RemoveRelations, after we have acquired our locks on the parent partitioned table and index. While at it, do some refactoring to eliminate confusion between the actual and expected relkind in RangeVarCallbackForDropRelation. We can save a couple of syscache lookups too, by having that function pass back info that RemoveRelations will need. Back-patch to v11 where partitioned indexes were added. Jimmy Yih, Gaurab Dey, Tom Lane Discussion: https://postgr.es/m/BYAPR05MB645402330042E17D91A70C12BD5F9@BYAPR05MB6454.namprd05.prod.outlook.com 21 March 2022, 16:22:13 UTC
a1efc8f Tom Lane 20 March 2022, 16:39:40 UTC Doc: fix our example systemd script. The example used "TimeoutSec=0", but systemd's documented way to get the desired effect is "TimeoutSec=infinity". Discussion: https://postgr.es/m/164770078557.670.5467111518383664377@wrigleys.postgresql.org 20 March 2022, 16:39:48 UTC
c422e8d Michael Paquier 19 March 2022, 07:37:39 UTC doc: Mention SET TABLESPACE clause for ALTER MATERIALIZED VIEW This command flavor is supported, but there was nothing in the documentation about it. Author: Yugo Nagata Discussion: https://postgr.es/m/20220316133337.5dc9740abfa24c25ec9f67f5@sraoss.co.jp Backpatch-through: 10 19 March 2022, 07:37:39 UTC
ae8ec7f Tom Lane 18 March 2022, 20:01:42 UTC Fix incorrect xmlschema output for types timetz and timestamptz. The output of table_to_xmlschema() and allied functions includes a regex describing valid values for these types ... but the regex was itself invalid, as it failed to escape a literal "+" sign. Report and fix by Renan Soares Lopes. Back-patch to all supported branches. Discussion: https://postgr.es/m/7f6fabaa-3f8f-49ab-89ca-59fbfe633105@me.com 18 March 2022, 20:01:42 UTC
1d072bd Tom Lane 17 March 2022, 22:18:05 UTC Revert applying column aliases to the output of whole-row Vars. In commit bf7ca1587, I had the bright idea that we could make the result of a whole-row Var (that is, foo.*) track any column aliases that had been applied to the FROM entry the Var refers to. However, that's not terribly logically consistent, because now the output of the Var is no longer of the named composite type that the Var claims to emit. bf7ca1587 tried to handle that by changing the output tuple values to be labeled with a blessed RECORD type, but that's really pretty disastrous: we can wind up storing such tuples onto disk, whereupon they're not readable by other sessions. The only practical fix I can see is to give up on what bf7ca1587 tried to do, and say that the column names of tuples produced by a whole-row Var are always those of the underlying named composite type, query aliases or no. While this introduces some inconsistencies, it removes others, so it's not that awful in the abstract. What *is* kind of awful is to make such a behavioral change in a back-patched bug fix. But corrupt data is worse, so back-patched it will be. (A workaround available to anyone who's unhappy about this is to introduce an extra level of sub-SELECT, so that the whole-row Var is referring to the sub-SELECT's output and not to a named table type. Then the Var is of type RECORD to begin with and there's no issue.) Per report from Miles Delahunty. The faulty commit dates to 9.5, so back-patch to all supported branches. Discussion: https://postgr.es/m/2950001.1638729947@sss.pgh.pa.us 17 March 2022, 22:18:05 UTC
677a1dc Tomas Vondra 16 March 2022, 15:42:47 UTC Fix publish_as_relid with multiple publications Commit 83fd4532a7 allowed publishing of changes via ancestors, for publications defined with publish_via_partition_root. But the way the ancestor was determined in get_rel_sync_entry() was incorrect, simply updating the same variable. So with multiple publications, replicating different ancestors, the outcome depended on the order of publications in the list - the value from the last loop was used, even if it wasn't the top-most ancestor. This is a probably rare situation, as in most cases publications do not overlap, so each partition has exactly one candidate ancestor to replicate as and there's no ambiguity. Fixed by tracking the "ancestor level" for each publication, and picking the top-most ancestor. Adds a test case, verifying the correct ancestor is used for publishing the changes and that this does not depend on order of publications in the list. Older releases have another bug in this loop - once all actions are replicated, the loop is terminated, on the assumption that inspecting additional publications is unecessary. But that misses the fact that those additional applications may replicate different ancestors. Fixed by removal of this break condition. We might still terminate the loop in some cases (e.g. when replicating all actions and the ancestor is the partition root). Backpatch to 13, where publish_via_partition_root was introduced. Initial report and fix by me, test added by Hou zj. Reviews and improvements by Amit Kapila. Author: Tomas Vondra, Hou zj, Amit Kapila Reviewed-by: Amit Kapila, Hou zj Discussion: https://postgr.es/m/d26d24dd-2fab-3c48-0162-2b7f84a9c893%40enterprisedb.com 16 March 2022, 17:06:27 UTC
7d30f59 Alexander Korotkov 16 March 2022, 08:41:18 UTC Fix default signature length for gist_ltree_ops 911e702077 implemented operator class parameters including the signature length in ltree. Previously, the signature length for gist_ltree_ops was 8. Because of bug 911e702077 the default signature length for gist_ltree_ops became 28 for ltree 1.1 (where options method is NOT provided) and 8 for ltree 1.2 (where options method is provided). This commit changes the default signature length for ltree 1.1 to 8. Existing gist_ltree_ops indexes might be corrupted in various scenarios. Thus, we have to recommend reindexing all the gist_ltree_ops indexes after the upgrade. Reported-by: Victor Yegorov Reviewed-by: Tomas Vondra, Tom Lane, Andres Freund, Nikita Glukhov Reviewed-by: Andrew Dunstan Author: Tomas Vondra, Alexander Korotkov Discussion: https://postgr.es/m/17406-71e02820ae79bb40%40postgresql.org Discussion: https://postgr.es/m/d80e0a55-6c3e-5b26-53e3-3c4f973f737c%40enterprisedb.com 16 March 2022, 08:41:30 UTC
26e0079 Thomas Munro 16 March 2022, 04:20:24 UTC Fix race between DROP TABLESPACE and checkpointing. Commands like ALTER TABLE SET TABLESPACE may leave files for the next checkpoint to clean up. If such files are not removed by the time DROP TABLESPACE is called, we request a checkpoint so that they are deleted. However, there is presently a window before checkpoint start where new unlink requests won't be scheduled until the following checkpoint. This means that the checkpoint forced by DROP TABLESPACE might not remove the files we expect it to remove, and the following ERROR will be emitted: ERROR: tablespace "mytblspc" is not empty To fix, add a call to AbsorbSyncRequests() just before advancing the unlink cycle counter. This ensures that any unlink requests forwarded prior to checkpoint start (i.e., when ckpt_started is incremented) will be processed by the current checkpoint. Since AbsorbSyncRequests() performs memory allocations, it cannot be called within a critical section, so we also need to move SyncPreCheckpoint() to before CreateCheckPoint()'s critical section. This is an old bug, so back-patch to all supported versions. Author: Nathan Bossart <nathandbossart@gmail.com> Reported-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220215235845.GA2665318%40nathanxps13 16 March 2022, 04:20:50 UTC
dc5b3bd Michael Paquier 16 March 2022, 03:29:47 UTC pageinspect: Fix memory context allocation of page in brin_revmap_data() This caused the function to fail, as the aligned copy of the raw page given by the function caller was not saved in the correct memory context, which needs to be multi_call_memory_ctx in this case. Issue introduced by 076f4d9. Per buildfarm members sifika, mylodon and longfin. I have reproduced that locally with macos. Discussion: https://postgr.es/m/YjFPOtfCW6yLXUeM@paquier.xyz Backpatch-through: 10 16 March 2022, 03:29:47 UTC
ea70f69 Thomas Munro 16 March 2022, 02:53:28 UTC Fix documentation typo in commit 5e6368b4. Back-patch to 14. 16 March 2022, 02:56:41 UTC
1396b5c Thomas Munro 16 March 2022, 02:35:42 UTC Fix waiting in RegisterSyncRequest(). If we run out of space in the checkpointer sync request queue (which is hopefully rare on real systems, but common with very small buffer pool), we wait for it to drain. While waiting, we should report that as a wait event so that users know what is going on, and also handle postmaster death, since otherwise the loop might never terminate if the checkpointer has exited. Back-patch to 12. Although the problem exists in earlier releases too, the code is structured differently before 12 so I haven't gone any further for now, in the absence of field complaints. Reported-by: Andres Freund <andres@anarazel.de> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220226213942.nb7uvb2pamyu26dj%40alap3.anarazel.de 16 March 2022, 02:35:42 UTC
b61e621 Michael Paquier 16 March 2022, 02:20:47 UTC pageinspect: Fix handling of page sizes and AM types This commit fixes a set of issues related to the use of the SQL functions in this module when the caller is able to pass down raw page data as input argument: - The page size check was fuzzy in a couple of places, sometimes looking after only a sub-range, but what we are looking for is an exact match on BLCKSZ. After considering a few options here, I have settled down to do a generalization of get_page_from_raw(). Most of the SQL functions already used that, and this is not strictly required if not accessing an 8-byte-wide value from a raw page, but this feels safer in the long run for alignment-picky environment, particularly if a code path begins to access such values. This also reduces the number of strings that need to be translated. - The BRIN function brin_page_items() uses a Relation but it did not check the access method of the opened index, potentially leading to crashes. All the other functions in need of a Relation already did that. - Some code paths could fail on elog(), but we should to use ereport() for failures that can be triggered by the user. Tests are added to stress all the cases that are fixed as of this commit, with some junk raw pages (\set VERBOSITY ensures that this works across all page sizes) and unexpected index types when functions open relations. Author: Michael Paquier, Justin Prysby Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com Backpatch-through: 10 16 March 2022, 02:20:47 UTC
78c0f85 Thomas Munro 16 March 2022, 00:37:58 UTC Wake up for latches in CheckpointWriteDelay(). The checkpointer shouldn't ignore its latch. Other backends may be waiting for it to drain the request queue. Hopefully real systems don't have a full queue often, but the condition is reached easily when shared_buffers is small. This involves defining a new wait event, which will appear in the pg_stat_activity view often due to spread checkpoints. Back-patch only to 14. Even though the problem exists in earlier branches too, it's hard to hit there. In 14 we stopped using signal handlers for latches on Linux, *BSD and macOS, which were previously hiding this problem by interrupting the sleep (though not reliably, as the signal could arrive before the sleep begins; precisely the problem latches address). Reported-by: Andres Freund <andres@anarazel.de> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220226213942.nb7uvb2pamyu26dj%40alap3.anarazel.de 16 March 2022, 00:57:07 UTC
d9f7ad5 Thomas Munro 15 March 2022, 22:35:00 UTC Back-patch LLVM 14 API changes. Since LLVM 14 has stopped changing and is about to be released, back-patch the following changes from the master branch: e6a7600202105919bffd62b3dfd941f4a94e082b 807fee1a39de6bb8184082012e643951abb9ad1d a56e7b66010f330782243de9e25ac2a6596be0e1 Back-patch to 11, where LLVM JIT support came in. 15 March 2022, 22:42:00 UTC
8dcd1c3 Tom Lane 11 March 2022, 18:47:26 UTC Restore the previous semantics of get_constraint_index(). Commit 8b069ef5d changed this function to look at pg_constraint.conindid rather than searching pg_depend. That was a good performance improvement, but it failed to preserve the exact semantics. The old code would only return an index that was "owned by" (internally dependent on) the specified constraint, whereas the new code will also return indexes that are just referenced by foreign key constraints. This confuses ALTER TABLE, which was implicitly expecting the previous semantics, into failing with errors like ERROR: relation 146621 has multiple clustered indexes or ERROR: "pk_attbl" is not an index for table "atref" We can fix this without reverting the performance improvement by adding a contype check in get_constraint_index(). Another way could be to make ALTER TABLE check it, but I'm worried that extension code could also have subtle dependencies on the old semantics. Tom Lane and Japin Li, per bug #17409 from Holly Roberts. Back-patch to v14 where the error crept in. Discussion: https://postgr.es/m/17409-52871dda8b5741cb@postgresql.org 11 March 2022, 18:47:26 UTC
8f09157 Michael Paquier 09 March 2022, 05:59:18 UTC doc: Add ALTER/DROP ROUTINE to the event trigger matrix ALTER ROUTINE triggers the events ddl_command_start and ddl_command_end, and DROP ROUTINE triggers sql_drop, ddl_command_start and ddl_command_end, but this was not mention on the matrix table. Reported-by: Leslie Lemaire Discussion: https://postgr.es/m/164647533363.646.5802968483136493025@wrigleys.postgresql.org Backpatch-through: 11 09 March 2022, 05:59:18 UTC
f60bb3e Noah Misch 05 March 2022, 02:53:13 UTC Introduce PG_TEST_TIMEOUT_DEFAULT for TAP suite non-elapsing timeouts. Slow hosts may avoid load-induced, spurious failures by setting environment variable PG_TEST_TIMEOUT_DEFAULT to some number of seconds greater than 180. Developers may see faster failures by setting that environment variable to some lesser number of seconds. In tests, write $PostgreSQL::Test::Utils::timeout_default wherever the convention has been to write 180. This change raises the default for some briefer timeouts. Back-patch to v10 (all supported versions). Discussion: https://postgr.es/m/20220218052842.GA3627003@rfd.leadboat.com 05 March 2022, 02:53:17 UTC
a008c03 Tom Lane 04 March 2022, 18:23:58 UTC Fix pg_regress to print the correct postmaster address on Windows. pg_regress reported "Unix socket" as the default location whenever HAVE_UNIX_SOCKETS is defined. However, that's not been accurate on Windows since 8f3ec75de. Update this logic to match what libpq actually does now. This is just cosmetic, but still it's potentially misleading. Back-patch to v13 where 8f3ec75de came in. Discussion: https://postgr.es/m/3894060.1646415641@sss.pgh.pa.us 04 March 2022, 18:23:58 UTC
5c9d17e Tom Lane 04 March 2022, 00:03:17 UTC Fix bogus casting in BlockIdGetBlockNumber(). This macro cast the result to BlockNumber after shifting, not before, which is the wrong thing. Per the C spec, the uint16 fields would promote to int not unsigned int, so that (for 32-bit int) the shift potentially shifts a nonzero bit into the sign position. I doubt there are any production systems where this would actually end with the wrong answer, but it is undefined behavior per the C spec, and clang's -fsanitize=undefined option reputedly warns about it on some platforms. (I can't reproduce that right now, but the code is undeniably wrong per spec.) It's easy to fix by casting to BlockNumber (uint32) in the proper places. It's been wrong for ages, so back-patch to all supported branches. Report and patch by Zhihong Yu (cosmetic tweaking by me) Discussion: https://postgr.es/m/CALNJ-vT9r0DSsAOw9OXVJFxLENoVS_68kJ5x0p44atoYH+H4dg@mail.gmail.com 04 March 2022, 00:03:35 UTC
b0bc196 Tom Lane 03 March 2022, 23:13:24 UTC Clean up assorted failures under clang's -fsanitize=undefined checks. Most of these are cases where we could call memcpy() or other libc functions with a NULL pointer and a zero count, which is forbidden by POSIX even though every production version of libc allows it. We've fixed such things before in a piecemeal way, but apparently never made an effort to try to get them all. I don't claim that this patch does so either, but it gets every failure I observe in check-world, using clang 12.0.1 on current RHEL8. numeric.c has a different issue that the sanitizer doesn't like: "ln(-1.0)" will compute log10(0) and then try to assign the resulting -Inf to an integer variable. We don't actually use the result in such a case, so there's no live bug. Back-patch to all supported branches, with the idea that we might start running a buildfarm member that tests this case. This includes back-patching c1132aae3 (Check the size in COPY_POINTER_FIELD), which previously silenced some of these issues in copyfuncs.c. Discussion: https://postgr.es/m/CALNJ-vT9r0DSsAOw9OXVJFxLENoVS_68kJ5x0p44atoYH+H4dg@mail.gmail.com 03 March 2022, 23:13:24 UTC
2a1f846 Tom Lane 02 March 2022, 16:57:02 UTC Allow root-owned SSL private keys in libpq, not only the backend. This change makes libpq apply the same private-key-file ownership and permissions checks that we have used in the backend since commit 9a83564c5. Namely, that the private key can be owned by either the current user or root (with different file permissions allowed in the two cases). This allows system-wide management of key files, which is just as sensible on the client side as the server, particularly when the client is itself some application daemon. Sync the comments about this between libpq and the backend, too. Back-patch of a59c79564 and 50f03473e into all supported branches. David Steele Discussion: https://postgr.es/m/f4b7bc55-97ac-9e69-7398-335e212f7743@pgmasters.net 02 March 2022, 16:57:02 UTC
ac910bb Tom Lane 25 February 2022, 22:40:21 UTC Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net 25 February 2022, 22:40:43 UTC
9ff7fd9 Andres Freund 25 February 2022, 18:30:05 UTC pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ. When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while determining the wal_segment_size, pg_waldump checked errno, despite errno not being set by the short read. Resulting in a bogus error message. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota.ntt@gmail.com Backpatch: 11-, the bug was introducedin fc49e24fa 25 February 2022, 18:31:16 UTC
7d80e93 Heikki Linnakangas 24 February 2022, 12:34:06 UTC Fix data loss on crash after sorted GiST index build. If a checkpoint happens during the index build, and the system crashes after the checkpoint and the index build have finished, the data written to the index before the checkpoint started could be lost. The checkpoint won't have fsync'd it, and it won't be replayed at crash recovery either. Fix by calling smgrimmedsync() after the index build, just like in B-tree index build. Backpatch to v14 where the sorted GiST index build was introduced. Reported-by: Melanie Plageman Discussion: https://www.postgresql.org/message-id/CAAKRu_ZJJynimxKj5xYBSziL62-iEtPE+fx-B=JzR=jUtP92mw@mail.gmail.com 24 February 2022, 12:34:09 UTC
dd7c059 Tom Lane 23 February 2022, 16:10:46 UTC Re-allow underscore as first character of custom GUC names. Commit 3db826bd5 intended that valid_custom_variable_name's rules for valid identifiers match those of scan.l. However, I (tgl) had some kind of brain fade and put "_" in the wrong list. Fix by Japin Li, per bug #17415 from Daniel Polski. Discussion: https://postgr.es/m/17415-ebdb683d7e09a51c@postgresql.org 23 February 2022, 16:10:46 UTC
627c79a Michael Paquier 22 February 2022, 01:23:49 UTC Add compute_query_id = regress "regress" is a new mode added to compute_query_id aimed at facilitating regression testing when a module computing query IDs is loaded into the backend, like pg_stat_statements. It works the same way as "auto", meaning that query IDs are computed if a module enables it, except that query IDs are hidden in EXPLAIN outputs to ensure regression output stability. Like any GUCs of the kind (force_parallel_mode, etc.), this new configuration can be added to an instance's postgresql.conf, or just passed down with PGOPTIONS at command level. compute_query_id uses an enum for its set of option values, meaning that this addition ensures ABI compatibility. Using this new configuration mode allows installcheck-world to pass when running the tests on an instance with pg_stat_statements enabled, stabilizing the test output while checking the paths doing query ID computations. Reported-by: Anton Melnikov Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/1634283396.372373993@f75.i.mail.ru Discussion: https://postgr.es/m/YgHlxgc/OimuPYhH@paquier.xyz Backpatch-through: 14 22 February 2022, 01:23:49 UTC
back to top