Skip to main content

Browse the archive

https://github.com/postgres/postgres
02 May 2024, 11:03:54 UTC
sort by:
Revision Author Date Message Commit Date
164d174 Tom Lane 13 June 2022, 20:04:05 UTC Stamp 14.4. 13 June 2022, 20:04:05 UTC
cb31fc2 Peter Eisentraut 13 June 2022, 05:32:39 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: e9a1d874376107ca29ff102e5fbbaee41532217a 13 June 2022, 05:32:39 UTC
18f66a1 Tom Lane 10 June 2022, 20:38:15 UTC Doc: remove a04ccf6df from release notes, now that it's reverted. Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org 10 June 2022, 20:38:15 UTC
f25b551 Tom Lane 10 June 2022, 20:34:25 UTC Revert "Fix psql's single transaction mode on client-side errors with -c/-f switches". This reverts commits a04ccf6df et al. in the back branches only. There was some disagreement already over whether to back-patch 157f8739a, on the grounds that it is the sort of behavioral change that we don't like to back-patch. Furthermore, it now looks like the logic needs some more work, which we don't have time for before the upcoming 14.4 release. Revert for now, and perhaps reconsider later. Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org 10 June 2022, 20:34:25 UTC
03fa84a Tom Lane 10 June 2022, 17:47:19 UTC First-draft release notes for 14.4. 10 June 2022, 17:47:19 UTC
77c1d92 Tom Lane 10 June 2022, 14:35:57 UTC Un-break whole-row Vars referencing domain-over-composite types. In commit ec62cb0aa, I foolishly replaced ExecEvalWholeRowVar's lookup_rowtype_tupdesc_domain call with just lookup_rowtype_tupdesc, because I didn't see how a domain could be involved there, and there were no regression test cases to jog my memory. But the existing code was correct, so revert that change and add a test case showing why it's necessary. (Note: per comment in struct DatumTupleFields, it is correct to produce an output tuple that's labeled with the base composite type, not the domain; hence just blindly looking through the domain is correct here.) Per bug #17515 from Dan Kubb. Back-patch to v11 where domains over composites became a thing. Discussion: https://postgr.es/m/17515-a24737438363aca0@postgresql.org 10 June 2022, 14:35:57 UTC
0ccef41 Tom Lane 08 June 2022, 16:01:51 UTC Doc: copy-edit "jsonb Indexing" section. The patch introducing jsonpath dropped a para about that between two related examples, and didn't bother updating the introductory sentences that it falsified. The grammar was pretty shaky as well. 08 June 2022, 16:01:51 UTC
804a507 Peter Eisentraut 08 June 2022, 12:27:42 UTC Fix whitespace 08 June 2022, 12:27:42 UTC
cbcea3b David Rowley 08 June 2022, 00:39:44 UTC Harden Memoization code against broken data types Bug #17512 highlighted that a suitably broken data type could cause the backend to crash if either the hash function or equality function were in someway non-deterministic based on their input values. Such a data type could cause a crash of the backend due to some code which assumes that we'll always find a hash table entry corresponding to an item in the Memoize LRU list. Here we remove the assumption that we'll always find the entry corresponding to the given LRU list item and add run-time checks to verify we have found the given item in the cache. This is not a fix for bug #17512, but it will turn the crash reported by that bug report into an internal ERROR. Reported-by: Ales Zeleny Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAApHDvpxFSTwvoYWT7kmFVSZ9zLAeHb=S9vrz=RExMgSkQNWqw@mail.gmail.com Backpatch-through: 14, where Memoize was added. 08 June 2022, 00:39:44 UTC
5c3b5f7 Tom Lane 07 June 2022, 19:34:30 UTC Fix off-by-one loop termination condition in pg_stat_get_subscription(). pg_stat_get_subscription scanned one more LogicalRepWorker array entry than is really allocated. In the worst case this could lead to SIGSEGV, if the LogicalRepCtx data structure is near the end of shared memory. That seems quite unlikely though (thanks to the ordering of calls in CreateSharedMemoryAndSemaphores) and we've heard no field reports of it. A more likely misbehavior is one row of garbage data in the function's result, but even that is not real likely because of the check that the pid field matches some live backend. Report and fix by Kuntal Ghosh. This bug is old, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAGz5QCJykEDzW6jQK6Yz7Qh_PMtD=95de_7QoocbVR2Qy8hWZA@mail.gmail.com 07 June 2022, 19:34:30 UTC
32a85ee Tom Lane 06 June 2022, 15:26:57 UTC Don't fail on libpq-generated error reports in pg_amcheck. An error PGresult generated by libpq itself, such as a report of connection loss, won't have broken-down error fields. should_processing_continue() blithely assumed that PG_DIAG_SEVERITY_NONLOCALIZED would always be present, and would dump core if it wasn't. Per grepping to see if 6d157e7cb's mistake was repeated elsewhere. 06 June 2022, 15:26:57 UTC
a5dbca4 Tom Lane 06 June 2022, 15:20:21 UTC Don't fail on libpq-generated error reports in ecpg_raise_backend(). An error PGresult generated by libpq itself, such as a report of connection loss, won't have broken-down error fields. ecpg_raise_backend() blithely assumed that PG_DIAG_MESSAGE_PRIMARY would always be present, and would end up passing a NULL string pointer to snprintf when it isn't. That would typically crash before 3779ac62d, and it would fail to provide a useful error report in any case. Best practice is to substitute PQerrorMessage(conn) in such cases, so do that. Per bug #17421 from Masayuki Hirose. Back-patch to all supported branches. Discussion: https://postgr.es/m/17421-790ff887e3188874@postgresql.org 06 June 2022, 15:20:31 UTC
a04ccf6 Michael Paquier 06 June 2022, 02:07:22 UTC Fix psql's single transaction mode on client-side errors with -c/-f switches psql --single-transaction is able to handle multiple -c and -f switches in a single transaction since d5563d7d, but this had the surprising behavior of forcing a transaction COMMIT even if psql failed with an error in the client (for example incorrect path given to \copy), which would generate an error, but still commit any changes that were already applied in the backend. This commit makes the behavior more consistent, by enforcing a transaction ROLLBACK if any commands fail, both client-side and backend-side, so as no changes are applied if one error happens in any of them. Some tests are added on HEAD to provide some coverage about all that. Backend-side errors are unreliable as IPC::Run can complain on SIGPIPE if psql quits before reading a query result, but that should work properly in the case where any errors come from psql itself, which is what the original report is about. Reported-by: Christoph Berg Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org Backpatch-through: 10 06 June 2022, 02:07:22 UTC
c1ad804 Tom Lane 03 June 2022, 17:54:53 UTC Doc: improve example for intarray's uniq() function. The previous entry invited confusion between what uniq() does by itself and what it does when combined with sort(). The latter usage is pretty useful so we should show it, but add an additional example to clarify the results of uniq() alone. Per suggestion from Martin Kalcher. Back-patch to v13, where we switched to formatting that supports multiple examples. Discussion: https://postgr.es/m/165407884456.573551.8779012279828726162@wrigleys.postgresql.org 03 June 2022, 17:54:58 UTC
2223c2a Tom Lane 03 June 2022, 15:51:37 UTC Doc: fix incorrect bit-reversal in example of macaddr formatting. Will Mortensen (minor additional copy-editing by me) Discussion: https://postgr.es/m/CAMpnoC5Y6jiZHSA82FG+e_AqkwMg-i94EYqs1C_9kXXFc3_3Yw@mail.gmail.com 03 June 2022, 15:51:54 UTC
18e3b19 Etsuro Fujita 02 June 2022, 09:00:02 UTC Doc: Further fix CREATE FOREIGN TABLE synopsis. This patch fixes the partitioning synopsis in the Parameters section in the CREATE FOREIGN TABLE documentation. Follow-up for commit ce21a36cf. Back-patch to v11 where default partition was introduced. Reviewed by Amit Langote and Robert Haas. Discussion: https://postgr.es/m/CAPmGK17U5jEqVZuo3r38wB0VFWomEtJCBGn_h92HQzQ2sP-49Q%40mail.gmail.com 02 June 2022, 09:00:02 UTC
4e46726 Tom Lane 01 June 2022, 21:21:45 UTC Silence compiler warnings from some older compilers. Since a117cebd6, some older gcc versions issue "variable may be used uninitialized in this function" complaints for brin_summarize_range. Silence that using the same coding pattern as in bt_index_check_internal; arguably, a117cebd6 had too narrow a view of which compilers might give trouble. Nathan Bossart and Tom Lane. Back-patch as the previous commit was. Discussion: https://postgr.es/m/20220601163537.GA2331988@nathanxps13 01 June 2022, 21:21:45 UTC
1072e4c Tom Lane 01 June 2022, 20:15:47 UTC Fix pl/perl test case so it will still work under Perl 5.36. Perl 5.36 has reclassified the warning condition that this test case used, so that the expected error fails to appear. Tweak the test so it instead exercises a case that's handled the same way in all Perl versions of interest. This appears to meet our standards for back-patching into out-of-support branches: it changes no user-visible behavior but enables testing of old branches with newer tools. Hence, back-patch as far as 9.2. Dagfinn Ilmari Mannsåker, per report from Jitka Plesníková. Discussion: https://postgr.es/m/564579.1654093326@sss.pgh.pa.us 01 June 2022, 20:15:47 UTC
80cd99c Tom Lane 01 June 2022, 14:39:46 UTC Doc: fix a couple of erroneous examples. The example given for anyelement <@ anymultirange didn't return true as claimed; adjust it so it does. In passing, change a couple of sample results where the modern numeric-based logic produces a different number of trailing zeroes than before. Erik Rijkers Discussion: https://postgr.es/m/cc35735d-1ec1-5bb3-9e27-cddbab7afa23@xs4all.nl 01 June 2022, 14:39:46 UTC
f2a0060 David Rowley 01 June 2022, 00:46:18 UTC Doc: mention limitation of the number of resultset columns The PostgreSQL limitations section of the documents mentioned the limit on the number of columns that can exist in a table. Users might be surprised to find that there's also a limit on the number of columns that can exist in a targetlist. Users may experience restrictions which surprise them if they happened to select a large number of columns from several tables with many columns. Here we document that there is a limitation on this and mention what that limit actually is. Wording proposal by Alvaro Herrera Reported-by: Vladimir Sitnikov Author: Dave Crammer Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAB=Je-E18aTYpNqje4mT0iEADpeGLSzwUvo3H9kRRuDdsNo4aQ@mail.gmail.com Backpatch-through: 12, where the limitations section was added 01 June 2022, 00:46:18 UTC
a694cf4 Magnus Hagander 31 May 2022, 19:59:47 UTC Recommend scram-sha-256 instead of md5 authentication in docs PostgreSQL 14 changed the default to be scram-sha-256, so we should stop recommending the user to use md5 or even worse password. Suggested-By: Daniel Westermann Author: Jonathan S. Katz Backpatch-through: 14 Discussion: https://postgr.es/m/GV0P278MB0419A8BAC0B0B84AFA5263D9D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM 31 May 2022, 20:01:58 UTC
042b584 Alvaro Herrera 31 May 2022, 19:24:59 UTC Revert changes to CONCURRENTLY that "sped up" Xmin advance This reverts commit d9d076222f5b "VACUUM: ignore indexing operations with CONCURRENTLY". These changes caused indexes created with the CONCURRENTLY option to miss heap tuples that were HOT-updated and HOT-pruned during the index creation. Before these changes, HOT pruning would have been prevented by the Xmin of the transaction creating the index, but because this change was precisely to allow the Xmin to move forward ignoring that backend, now other backends scanning the table can prune them. This is not a problem for VACUUM (which requires a lock that conflicts with a CREATE INDEX CONCURRENTLY operation), but HOT-prune can definitely occur. In other words, Xmin advancement was sped up, but at the cost of corrupting the resulting index. Regrettably, this means that the new feature in PG14 that RIC/CIC on very large tables no longer force VACUUM to retain very old tuples goes away. We might try to implement it again in a later release, but for now the risk of indexes missing tuples is too high and there's no easy fix. Backpatch to 14, where this change appeared. Reported-by: Peter Slavov <pet.slavov@gmail.com> Diagnosys-by: Andrey Borodin <x4mmm@yandex-team.ru> Diagnosys-by: Michael Paquier <michael@paquier.xyz> Diagnosys-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org 31 May 2022, 19:24:59 UTC
c47a558 Tom Lane 31 May 2022, 18:47:44 UTC Ensure ParseTzFile() closes the input file after failing. We hadn't noticed this because (a) few people feed invalid timezone abbreviation files to the server, and (b) in typical scenarios guc.c would throw ereport(ERROR) and then transaction abort handling would silently clean up the leaked file reference. However, it was possible to observe file leakage warnings if one breaks an already-active abbreviation file, because guc.c does not throw ERROR when loading supposedly-validated settings during session start or SIGHUP processing. Report and fix by Kyotaro Horiguchi (cosmetic adjustments by me) Discussion: https://postgr.es/m/20220530.173740.748502979257582392.horikyota.ntt@gmail.com 31 May 2022, 18:47:44 UTC
a18b2a3 Tom Lane 31 May 2022, 16:14:02 UTC Doc: fix mention of pg_dump's minimum supported server version. runtime.sgml contains a passing reference to the minimum server version that pg_dump[all] can dump from. That was 7.0 for many years, but when 64f3524e2 raised it to 8.0, we missed updating this bit. Then when 30e7c175b raised it to 9.2, we missed it again. Given that track record, I'm not too hopeful that we'll remember to fix this in future changes ... but for now, make the docs match reality in each branch. Noted by Daniel Westermann. Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM 31 May 2022, 16:14:02 UTC
0adff38 Michael Paquier 30 May 2022, 01:50:32 UTC doc: Reword description of roles able to view track_activities's info The information generated when track_activities is accessible to superusers, roles with the privileges of pg_read_all_stats, as well as roles one has the privileges of. The original text did not outline the last point, while the change done in ac1ae47 was unclear about the second point. Per discussion with Nathan Bossart. Discussion: https://postgr.es/m/20220521185743.GA886636@nathanxps13 Backpatch-through: 10 30 May 2022, 01:50:32 UTC
f82595a Heikki Linnakangas 29 May 2022, 20:53:45 UTC Fix COPY FROM when database encoding is SQL_ASCII. In the codepath when no encoding conversion is required, the check for incomplete character at the end of input incorrectly used server encoding's max character length, instead of the client's. Usually the server and client encodings are the same when we're not performing encoding conversion, but SQL_ASCII is an exception. In the passing, also fix some outdated comments that still talked about the old COPY protocol. It was removed in v14. Per bug #17501 from Vitaly Voronov. Backpatch to v14 where this was introduced. Discussion: https://www.postgresql.org/message-id/17501-128b1dd039362ae6@postgresql.org 29 May 2022, 20:57:16 UTC
9f2d194 Tom Lane 29 May 2022, 17:25:21 UTC Doc: fix missing/bogus documentation of range_intersect_agg(). The form taking anymultirange had not been documented. This was fixed in HEAD in b21c4cf95, but that should have been back-patched to v14 since the function was added there. Do so now. Also, the form taking anyrange was incorrectly documented as returning anymultirange, when it returns anyrange. Remove b21c4cf95 from the v15 release notes, since it no longer qualifies as new-in-v15. Noted by Shay Rojansky. Discussion: https://postgr.es/m/CADT4RqAktzP7t6SFf0Xqm9YhahzvsmxFbzXe-gFOd=+_CHm0JA@mail.gmail.com 29 May 2022, 17:25:21 UTC
fe441a0 Michael Paquier 28 May 2022, 03:12:46 UTC Handle NULL for short descriptions of custom GUC variables If a short description is specified as NULL in one of the various DefineCustomXXXVariable() functions available to external modules to define a custom parameter, SHOW ALL would crash. This change teaches SHOW ALL to properly handle NULL short descriptions, as well as any code paths that manipulate it, to gain in flexibility. Note that help_config.c was already able to do that, when describing a set of GUCs for postgres --describe-config. Author: Steve Chavez Reviewed by: Nathan Bossart, Andres Freund, Michael Paquier, Tom Lane Discussion: https://postgr.es/m/CAGRrpzY6hO-Kmykna_XvsTv8P2DshGiU6G3j8yGao4mk0CqjHA%40mail.gmail.com Backpatch-through: 10 28 May 2022, 03:12:46 UTC
b4be4a0 Tom Lane 26 May 2022, 18:14:05 UTC Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/MW3PR15MB3931DF96896DC36D21AFD47CA3D39@MW3PR15MB3931.namprd15.prod.outlook.com 26 May 2022, 18:14:05 UTC
a5fc06b Robert Haas 26 May 2022, 16:54:57 UTC In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/20220521130922.GX19626@telsasoft.com 26 May 2022, 16:54:57 UTC
6f7eec1 Tom Lane 21 May 2022, 18:45:58 UTC Show 'AS "?column?"' explicitly when it's important. ruleutils.c was coded to suppress the AS label for a SELECT output expression if the column name is "?column?", which is the parser's fallback if it can't think of something better. This is fine, and avoids ugly clutter, so long as (1) nothing further up in the parse tree relies on that column name or (2) the same fallback would be assigned when the rule or view definition is reloaded. Unfortunately (2) is far from certain, both because ruleutils.c might print the expression in a different form from how it was originally written and because FigureColname's rules might change in future releases. So we shouldn't rely on that. Detecting exactly whether there is any outer-level use of a SELECT column name would be rather expensive. This patch takes the simpler approach of just passing down a flag indicating whether there *could* be any outer use; for example, the output column names of a SubLink are not referenceable, and we also do not care about the names exposed by the right-hand side of a setop. This is sufficient to suppress unwanted clutter in all but one case in the regression tests. That seems like reasonable evidence that it won't be too much in users' faces, while still fixing the cases we need to fix. Per bug #17486 from Nicolas Lutic. This issue is ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/17486-1ad6fd786728b8af@postgresql.org 21 May 2022, 18:45:58 UTC
7f798e8 Michael Paquier 21 May 2022, 10:05:54 UTC doc: Mention pg_read_all_stats in description of track_activities The description of track_activities mentioned that it is visible to superusers and that the information related to the current session can be seen, without telling about pg_read_all_stats. Roles that are granted the privileges of pg_read_all_stats can also see this information, so mention it in the docs. Author: Ian Barwick Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/CAB8KJ=jhPyYFu-A5r-ZGP+Ax715mUKsMxAGcEQ9Cx_mBAmrPow@mail.gmail.com Backpatch-through: 10 21 May 2022, 10:05:54 UTC
58b088a Alvaro Herrera 20 May 2022, 16:52:55 UTC Fix DDL deparse of CREATE OPERATOR CLASS When an implicit operator family is created, it wasn't getting reported. Make it do so. This has always been missing. Backpatch to 10. Author: Masahiko Sawada <sawada.mshk@gmail.com> Reported-by: Leslie LEMAIRE <leslie.lemaire@developpement-durable.gouv.fr> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Michael Paquiër <michael@paquier.xyz> Discussion: https://postgr.es/m/f74d69e151b22171e8829551b1159e77@developpement-durable.gouv.fr 20 May 2022, 16:52:55 UTC
aa78357 Alvaro Herrera 20 May 2022, 08:05:31 UTC doc: Explain 'invalid' index state for CREATE INDEX CONCURRENTLY It wasn't previously mentioned that the index is created as invalid, which is confusing to new users. Backpatch to 14 (only because of a conflict in 13). Author: Laurenz Albe <laurenz.albe@cybertec.at> Reported-by: Lauren Fliksteen <dancernerd32@gmail.com> Reviewed-by: Rajakavitha Kodhandapani <krajakavitha@gmail.com> Discussion: https://postgr.es/m/165290238488.670.7500177735573254738@wrigleys.postgresql.org 20 May 2022, 08:05:31 UTC
3a8d83c Tom Lane 19 May 2022, 22:36:07 UTC Doc: clarify location of libpq's default service file on Windows. The documentation didn't specify the name of the per-user service file on Windows, and extrapolating from the pattern used for other config files gave the wrong answer. The fact that it isn't consistent with the others sure seems like a bug, but it's far too late to change that now; we'd just penalize people who worked it out in the past. So, simply document the true state of affairs. In passing, fix some gratuitous differences between the discussions of the service file and the password file. Julien Rouhaud, per question from Dominique Devienne. Backpatch to all supported branches. I (tgl) also chose to back-patch the part of commit ba356a397 that touched libpq.sgml's description of the service file --- in hindsight, I'm not sure why I didn't do so at the time, as it includes some fairly essential information. Discussion: https://postgr.es/m/CAFCRh-_mdLrh8eYVzhRzu4c8bAFEBn=rwoHOmFJcQOTsCy5nig@mail.gmail.com 19 May 2022, 22:36:07 UTC
8d9d128 Alvaro Herrera 19 May 2022, 14:20:32 UTC Repurpose PROC_COPYABLE_FLAGS as PROC_XMIN_FLAGS This is a slight, convenient semantics change from what commit 0f0cfb494004 ("Fix parallel operations that prevent oldest xmin from advancing") introduced that lets us simplify the coding in the one place where it is used. Backpatch to 13. This is related to commit 6fea65508a1a ("Tighten ComputeXidHorizons' handling of walsenders") rewriting the code site where this is used, which has not yet been backpatched, but it may well be in the future. Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Discussion: https://postgr.es/m/202204191637.eldwa2exvguw@alvherre.pgsql 19 May 2022, 14:20:32 UTC
3f712ea David Rowley 19 May 2022, 05:14:56 UTC Fix incorrect comments for Memoize struct Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/0635f5aa-4973-8dc2-4e4e-df9fd5778a65@enterprisedb.com Backpatch-through: 14, where Memoize was added 19 May 2022, 05:14:56 UTC
e8b93c6 Alvaro Herrera 18 May 2022, 21:19:53 UTC Update xml_1.out and xml_2.out Commit 0fbf01120023 should have updated them but didn't. 18 May 2022, 21:19:53 UTC
94edb85 Alvaro Herrera 18 May 2022, 18:28:31 UTC Check column list length in XMLTABLE/JSON_TABLE alias We weren't checking the length of the column list in the alias clause of an XMLTABLE or JSON_TABLE function (a "tablefunc" RTE), and it was possible to make the server crash by passing an overly long one. Fix it by throwing an error in that case, like the other places that deal with alias lists. In passing, modify the equivalent test used for join RTEs to look like the other ones, which was different for no apparent reason. This bug came in when XMLTABLE was born in version 10; backpatch to all stable versions. Reported-by: Wang Ke <krking@zju.edu.cn> Discussion: https://postgr.es/m/17480-1c9d73565bb28e90@postgresql.org 18 May 2022, 18:28:31 UTC
23c2b76 David Rowley 16 May 2022, 04:08:37 UTC Fix incorrect row estimates used for Memoize costing In order to estimate the cache hit ratio of a Memoize node, one of the inputs we require is the estimated number of times the Memoize node will be rescanned. The higher this number, the large the cache hit ratio is likely to become. Unfortunately, the value being passed as the number of "calls" to the Memoize was incorrectly using the Nested Loop's outer_path->parent->rows instead of outer_path->rows. This failed to account for the fact that the outer_path might be parameterized by some upper-level Nested Loop. This problem could lead to Memoize plans appearing more favorable than they might actually be. It could also lead to extended executor startup times when work_mem values were large due to the planner setting overly large MemoizePath->est_entries resulting in the Memoize hash table being initially made much larger than might be required. Fix this simply by passing outer_path->rows rather than outer_path->parent->rows. Also, adjust the expected regression test output for a plan change. Reported-by: Pavel Stehule Author: David Rowley Discussion: https://postgr.es/m/CAFj8pRAMp%3DQsMi6sPQJ4W3hczoFJRvyXHJV3AZAZaMyTVM312Q%40mail.gmail.com Backpatch-through: 14, where Memoize was introduced 16 May 2022, 04:08:37 UTC
6dced63 Michael Paquier 16 May 2022, 02:26:22 UTC Fix control file update done in restartpoints still running after promotion If a cluster is promoted (aka the control file shows a state different than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still processing, this function could miss an update of the control file for "checkPoint" and "checkPointCopy" but still do the recycling and/or removal of the past WAL segments, assuming that the to-be-updated LSN values should be used as reference points for the cleanup. This causes a follow-up restart attempting crash recovery to fail with a PANIC on a missing checkpoint record if the end-of-recovery checkpoint triggered by the promotion did not complete while the cluster abruptly stopped or crashed before the completion of this checkpoint. The PANIC would be caused by the redo LSN referred in the control file as located in a segment already gone, recycled by the previous restartpoint with "checkPoint" out-of-sync in the control file. This commit fixes the update of the control file during restartpoints so as "checkPoint" and "checkPointCopy" are updated even if the cluster has been promoted while a restartpoint is running, to be on par with the set of WAL segments actually recycled in the end of CreateRestartPoint(). 7863ee4 has fixed this problem already on master, but the release timing of the latest point versions did not let me enough time to study and fix that on all the stable branches. Reported-by: Fujii Masao, Rui Zhao Author: Kyotaro Horiguchi Reviewed-by: Nathan Bossart, Michael Paquier Discussion: https://postgr.es/m/20220316.102444.2193181487576617583.horikyota.ntt@gmail.com Backpatch-through: 10 16 May 2022, 02:26:22 UTC
ac51c9f Tom Lane 12 May 2022, 15:31:46 UTC Make pull_var_clause() handle GroupingFuncs exactly like Aggrefs. This follows in the footsteps of commit 2591ee8ec by removing one more ill-advised shortcut from planning of GroupingFuncs. It's true that we don't intend to execute the argument expression(s) at runtime, but we still have to process any Vars appearing within them, or we risk failure at setrefs.c time (or more fundamentally, in EXPLAIN trying to print such an expression). Vars in upper plan nodes have to have referents in the next plan level, whether we ever execute 'em or not. Per bug #17479 from Michael J. Sullivan. Back-patch to all supported branches. Richard Guo Discussion: https://postgr.es/m/17479-6260deceaf0ad304@postgresql.org 12 May 2022, 15:31:46 UTC
d6da71f Amit Kapila 11 May 2022, 05:21:04 UTC Fix the logical replication timeout during large transactions. The problem is that we don't send keep-alive messages for a long time while processing large transactions during logical replication where we don't send any data of such transactions. This can happen when the table modified in the transaction is not published or because all the changes got filtered. We do try to send the keep_alive if necessary at the end of the transaction (via WalSndWriteData()) but by that time the subscriber-side can timeout and exit. To fix this we try to send the keepalive message if required after processing certain threshold of changes. Reported-by: Fabrice Chapuis Author: Wang wei and Amit Kapila Reviewed By: Masahiko Sawada, Euler Taveira, Hou Zhijie, Hayato Kuroda Backpatch-through: 10 Discussion: https://postgr.es/m/CAA5-nLARN7-3SLU_QUxfy510pmrYK6JJb=bk3hcgemAM_pAv+w@mail.gmail.com 11 May 2022, 05:21:04 UTC
ca9e9b0 Michael Paquier 11 May 2022, 01:22:29 UTC Improve setup of environment values for commands in MSVC's vcregress.pl The current setup assumes that commands for lz4, zstd and gzip always exist by default if not enforced by a user's environment. However, vcpkg, as one example, installs libraries but no binaries, so this default setup to assume that a command should always be present would cause failures. This commit improves the detection of such external commands as follows: * If a ENV value is available, trust the environment/user and use it. * If a ENV value is not available, check its execution by looking in the current PATH, by launching a simple "$command --version" (that should be portable enough). ** On execution failure, ignore ENV{command}. ** On execution success, set ENV{command} = "$command". Note that this new rule applies to gzip, lz4 and zstd but not tar that we assume will always exist. Those commands are set up in the environment only when using bincheck and taptest. The CI includes all those commands and I have checked that their setup is correct there. I have also tested this change in a MSVC environment where we have none of those commands. While on it, remove the references to lz4 from the documentation and vcregress.pl in ~v13. --with-lz4 has been added in v14~ so there is no point to have this information in these older branches. Reported-by: Andrew Dunstan Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/14402151-376b-a57a-6d0c-10ad12608e12@dunslane.net Backpatch-through: 10 11 May 2022, 01:22:29 UTC
12736e7 Tom Lane 10 May 2022, 22:42:02 UTC configure: don't probe for libldap_r if libldap is 2.5 or newer. In OpenLDAP 2.5 and later, libldap itself is always thread-safe and there's never a libldap_r. Our existing coding dealt with that by assuming it wouldn't find libldap_r if libldap is thread-safe. But that rule fails to cope if there are multiple OpenLDAP versions visible, as is likely to be the case on macOS in particular. We'd end up using shiny new libldap in the backend and a hoary libldap_r in libpq. Instead, once we've found libldap, check if it's >= 2.5 (by probing for a function introduced then) and don't bother looking for libldap_r if so. While one can imagine library setups that this'd still give the wrong answer for, they seem unlikely to occur in practice. Per report from Peter Eisentraut. Back-patch to all supported branches. Discussion: https://postgr.es/m/fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com 10 May 2022, 22:42:02 UTC
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
back to top