PostgreSQL 14 Beta 2 released. Test!
The 12th PostgreSQL Conference Cuba (PostgresqlCUBA, @PgCuba) will take place on November 18-19, 2021, at the Hotel Habana Libre. This event is part of the TECNOGET conference, and we will host one track dedicated to PostgreSQL related talks. For more details, reach out to cu AT postgresql DOT org.
JDBC 42.2.22 released
pgpoolAdmin 4.2.0, the administration tool for Pgpool-II, released.
pgCenter 0.9.0, a command-line admin tool for observing and troubleshooting PostgreSQL, released
https://archives.postgresql.org/pgsql-jobs/2021-06/
Planet PostgreSQL: https://planet.postgresql.org/
PostgreSQL Weekly News is brought to you this week by David Fetter
Submit news and announcements by Sunday at 3:00pm PST8PDT to david@fetter.org.
Tom Lane pushed:
Work around portability issue with newer versions of mktime(). Recent glibc versions have made mktime() fail if tm_isdst is inconsistent with the prevailing timezone; in particular it fails for tm_isdst = 1 when the zone is UTC. (This seems wildly inconsistent with the POSIX-mandated treatment of "incorrect" values for the other fields of struct tm, so if you ask me it's a bug, but I bet they'll say it's intentional.) This has been observed to cause cosmetic problems when pg_restore'ing an archive created in a different timezone. To fix, do mktime() using the field values from the archive, and if that fails try again with tm_isdst = -1. This will give a result that's off by the UTC-offset difference from the original zone, but that was true before, too. It's not terribly critical since we don't do anything with the result except possibly print it. (Someday we should flush this entire bit of logic and record a standard-format timestamp in the archive instead. That's not okay for a back-patched bug fix, though.) Also, guard our only other use of mktime() by having initdb's build_time_t() set tm_isdst = -1 not 0. This case could only have an issue in zones that are DST year-round; but I think some do exist, or could in future. Per report from Wells Oliver. Back-patch to all supported versions, since any of them might need to run with a newer glibc. Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f807e3410fdfc29ced6590c7c2afa76637e001ad
Remove orphaned expected-result file. This should have been removed in 43e084197, which removed the corresponding spec file. Noted while fooling about with the isolationtester. https://git.postgresql.org/pg/commitdiff/ffbe9dec13599fa786ea6567df1c6a3f3ee3c673
Update variant expected-result file. This should have been updated in d2d8a229b, but it was overlooked. According to 31a877f18 which added it, this file is meant to show the results you get under default_transaction_isolation = serializable. We've largely lost track of that goal in other isolation tests, but as long as we've got this one, it should be right. Noted while fooling about with the isolationtester. https://git.postgresql.org/pg/commitdiff/0a1e80c5c4f094087257fc4284a87e0bc7bca591
Remove another orphan expected-result file. aborted-keyrevoke_2.out was apparently needed when it was added (in commit 0ac5ad513) to handle the case of serializable transaction mode. However, the output in serializable mode actually matches the regular aborted-keyrevoke.out file, and AFAICT has done so for a long time. There's no need to keep dragging this variant along. https://git.postgresql.org/pg/commitdiff/f6352a0d4e437ac8bc266f77df22d064592056c9
Update another variant expected-result file. This should have been updated in 533e9c6b0, but it was overlooked. Given the lack of complaints, I won't bother back-patching. https://git.postgresql.org/pg/commitdiff/d3c878499c9d639ff06e0664d06b8c731e30c2fc
Improve SQLSTATE reporting in some replication-related code. I started out with the goal of reporting ERRCODE_CONNECTION_FAILURE when walrcv_connect() fails, but as I looked around I realized that whoever wrote this code was of the opinion that errcodes are purely optional. That's not my understanding of our project policy. Hence, make sure that an errcode is provided in each ereport that (a) is ERROR or higher level and (b) isn't arguably an internal logic error. Also fix some very dubious existing errcode assignments. While this is not per policy, it's also largely cosmetic, since few of these cases could get reported to applications. So I don't feel a need to back-patch. Discussion: https://postgr.es/m/2189704.1623512522@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6b787d9e32005867ee3660d1ea20f447810a403d
Fix plancache refcount leak after error in ExecuteQuery. When stuffing a plan from the plancache into a Portal, one is not supposed to risk throwing an error between GetCachedPlan and PortalDefineQuery; if that happens, the plan refcount incremented by GetCachedPlan will be leaked. I managed to break this rule while refactoring code in 9dbf2b7d7. There is no visible consequence other than some memory leakage, and since nobody is very likely to trigger the relevant error conditions many times in a row, it's not surprising we haven't noticed. Nonetheless, it's a bug, so rearrange the order of operations to remove the hazard. Noted on the way to looking for a better fix for bug #17053. This mistake is pretty old, so back-patch to all supported branches. https://git.postgresql.org/pg/commitdiff/131ea3e908d3c97a2fe1ab25cce5046dd5cb905f
Centralize the logic for protective copying of utility statements. In the "simple Query" code path, it's fine for parse analysis or execution of a utility statement to scribble on the statement's node tree, since that'll just be thrown away afterwards. However it's not fine if the node tree is in the plan cache, as then it'd be corrupted for subsequent executions. Up to now we've dealt with that by having individual utility-statement functions apply copyObject() if they were going to modify the tree. But that's prone to errors of omission. Bug #17053 from Charles Samborski shows that CREATE/ALTER DOMAIN didn't get this memo, and can crash if executed repeatedly from plan cache. In the back branches, we'll just apply a narrow band-aid for that, but in HEAD it seems prudent to have a more principled fix that will close off the possibility of other similar bugs in future. Hence, let's hoist the responsibility for doing copyObject up into ProcessUtility from its children, thus ensuring that it happens for all utility statement types. Also, modify ProcessUtility's API so that its callers can tell it whether a copy step is necessary. It turns out that in all cases, the immediate caller knows whether the node tree is transient, so this doesn't involve a huge amount of code thrashing. In this way, while we lose a little bit in the execute-from-cache code path due to sometimes copying node trees that wouldn't be mutated anyway, we gain something in the simple-Query code path by not copying throwaway node trees. Statements that are complex enough to be expensive to copy are almost certainly ones that would have to be copied anyway, so the loss in the cache code path shouldn't be much. (Note that this whole problem applies only to utility statements. Optimizable statements don't have the issue because we long ago made the executor treat Plan trees as read-only. Perhaps someday we will make utility statement execution act likewise, but I'm not holding my breath.) Discussion: https://postgr.es/m/931771.1623893989@sss.pgh.pa.us Discussion: https://postgr.es/m/17053-3ca3f501bbc212b4@postgresql.org https://git.postgresql.org/pg/commitdiff/7c337b6b527b7052e6a751f966d5734c56f668b5
Improve version reporting in pgbench. Commit 547f04e73 caused pgbench to start printing its version number, which seems like a fine idea, but it needs a bit more work: * Print the server version number too, when different. * Print the PG_VERSION string, not some reconstructed approximation. This patch copies psql's well-tested code for the same purpose. Discussion: https://postgr.es/m/1226654.1624036821@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/84bee9610965331d5110971d8de390a5bbe2effc
Fix misbehavior of DROP OWNED BY with duplicate polroles entries. Ordinarily, a pg_policy.polroles array wouldn't list the same role more than once; but CREATE POLICY does not prevent that. If we perform DROP OWNED BY on a role that is listed more than once, RemoveRoleFromObjectPolicy either suffered an assertion failure or encountered a tuple-updated-by-self error. Rewrite it to cope correctly with duplicate entries, and add a CommandCounterIncrement call to prevent the other problem. Per discussion, there's other cleanup that ought to happen here, but this seems like the minimum essential fix. Per bug #17062 from Alexander Lakhin. It's been broken all along, so back-patch to all supported branches. Discussion: https://postgr.es/m/17062-11f471ae3199ca23@postgresql.org https://git.postgresql.org/pg/commitdiff/d21fca084356946664bfce19d66d2df2bb873cbd
Provide feature-test macros for libpq features added in v14. We had a request to provide a way to test at compile time for the availability of the new pipeline features. More generally, it seems like a good idea to provide a way to test via #ifdef for all new libpq API features. People have been using the version from pg_config.h for that; but that's more likely to represent the server version than the libpq version, in the increasingly-common scenario where they're different. It's safer if libpq-fe.h itself is the source of truth about what features it offers. Hence, establish a policy that starting in v14 we'll add a suitable feature-is-present macro to libpq-fe.h when we add new API there. (There doesn't seem to be much point in applying this policy retroactively, but it's not too late for v14.) Tom Lane and Alvaro Herrera, per suggestion from Boris Kolpackov. Discussion: https://postgr.es/m/boris.20210617102439@codesynthesis.com https://git.postgresql.org/pg/commitdiff/6991e774e0304f5ef488cf1ae4fa79578b6ae3d5
Stabilize test case added by commit f61db909d. Buildfarm members ayu and tern have sometimes shown a different plan than expected for this query. I'd been unable to reproduce that before today, but I finally realized what is happening. If there is a concurrent open transaction (probably an autovacuum run in the buildfarm, but this can also be arranged manually), then the index entries for the rows removed by the DELETE a few lines up are not killed promptly, causing a change in the planner's estimate of the extremal value of ft2.c1, which moves the rowcount estimate for "c1 > 1100" by enough to change the join plan from nestloop to hash. To fix, change the query condition to "c1 > 1000", causing the hash plan to be preferred whether or not a concurrent open transaction exists. Since this UPDATE is tailored to be a no-op, nothing else changes. Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-09%2022%3A45%3A48 Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-13%2022%3A38%3A18 Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2021-06-20%2004%3A55%3A36 https://git.postgresql.org/pg/commitdiff/5843659d091bfb6f2c60e010ea1fd00e55ee6ada
Restore the portal-level snapshot for simple expressions, too. Commits 84f5c2908 et al missed the need to cover plpgsql's "simple expression" code path. If the first thing we execute after a COMMIT/ROLLBACK is one of those, rather than a full-fledged SPI command, we must explicitly do EnsurePortalSnapshotExists() to make sure we have an outer snapshot. Note that it wouldn't be good enough to just push a snapshot for the duration of the expression execution: what comes back might be toasted, so we'd better have a snapshot protecting it. The test case demonstrating this fact cheats a bit by marking a SQL function immutable even though it fetches from a table. That's nothing that users haven't been seen to do, though. Per report from Jim Nasby. Back-patch to v11, like the previous fix. Discussion: https://postgr.es/m/378885e4-f85f-fc28-6c91-c4d1c080bf26@amazon.com https://git.postgresql.org/pg/commitdiff/d102aafb6259a6a412803d4b1d8c4f00aa17f67e
Use annotations to reduce instability of isolation-test results. We've long contended with isolation test results that aren't entirely stable. Some test scripts insert long delays to try to force stable results, which is not terribly desirable; but other erratic failure modes remain, causing unrepeatable buildfarm failures. I've spent a fair amount of time trying to solve this by improving the server-side support code, without much success: that way is fundamentally unable to cope with diffs that stem from chance ordering of arrival of messages from different server processes. We can improve matters on the client side, however, by annotating the test scripts themselves to show the desired reporting order of events that might occur in different orders. This patch adds three types of annotations to deal with (a) test steps that might or might not complete their waits before the isolationtester can see them waiting; (b) test steps in different sessions that can legitimately complete in either order; and (c) NOTIFY messages that might arrive before or after the completion of a step in another session. We might need more annotation types later, but this seems to be enough to deal with the instabilities we've seen in the buildfarm. It also lets us get rid of all the long delays that were previously used, cutting more than a minute off the runtime of the isolation tests. Back-patch to all supported branches, because the buildfarm instabilities affect all the branches, and because it seems desirable to keep isolationtester's capabilities the same across all branches to simplify possible future back-patching of tests. Discussion: https://postgr.es/m/327948.1623725828@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/741d7f1047fe52da7ced6fa9cea661ce9320c8d4
Improve display of query results in isolation tests. Previously, isolationtester displayed SQL query results using some ad-hoc code that clearly hadn't had much effort expended on it. Field values longer than 14 characters weren't separated from the next field, and usually caused misalignment of the columns too. Also there was no visual separation of a query's result from subsequent isolationtester output. This made test result files confusing and hard to read. To improve matters, let's use libpq's PQprint() function. Although that's long since unused by psql, it's still plenty good enough for the purpose here. Like 741d7f104, back-patch to all supported branches, so that this isn't a stumbling block for back-patching isolation test changes. Discussion: https://postgr.es/m/582362.1623798221@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/4a054069a36032a59afceb07f3b837f09ab1a2e9
Don't assume GSSAPI result strings are null-terminated. Our uses of gss_display_status() and gss_display_name() assumed that the gss_buffer_desc strings returned by those functions are null-terminated. It appears that they generally are, given the lack of field complaints up to now. However, the available documentation does not promise this, and some man pages for gss_display_status() show examples that rely on the gss_buffer_desc.length field instead of expecting null termination. Also, we now have a report that on some implementations, clang's address sanitizer is of the opinion that the byte after the specified length is undefined. Hence, change the code to rely on the length field instead. This might well be cosmetic rather than fixing any real bug, but it's hard to be sure, so back-patch to all supported branches. While here, also back-patch the v12 changes that made pg_GSS_error deal honestly with multiple messages available from gss_display_status. Per report from Sudheer H R. Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com https://git.postgresql.org/pg/commitdiff/126cdaf47af275f76b2f2ddb023bfdc6f018ae30
Doc: fix confusion about LEAKPROOF in syntax summaries. The syntax summaries for CREATE FUNCTION and allied commands made it look like LEAKPROOF is an alternative to IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal option. Improve that. Per gripe from aazamrafeeque0. Thanks to David Johnston for suggestions. Discussion: https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/2031e1668e5577e64cfed29da69a34903d5a5227
Allow non-quoted identifiers as isolation test session/step names. For no obvious reason, isolationtester has always insisted that session and step names be written with double quotes. This is fairly tedious and does little for test readability, especially since the names that people actually choose almost always look like normal identifiers. Hence, let's tweak the lexer to allow SQL-like identifiers not only double-quoted strings. (They're SQL-like, not exactly SQL, because I didn't add any case-folding logic. Also there's no provision for U&"..." names, not that anyone's likely to care.) There is one incompatibility introduced by this change: if you write "foo""bar" with no space, that used to be taken as two identifiers, but now it's just one identifier with an embedded quote mark. I converted all the src/test/isolation/ specfiles to remove unnecessary double quotes, but stopped there because my eyes were glazing over already. Like 741d7f104, back-patch to all supported branches, so that this isn't a stumbling block for back-patching isolation test changes. Discussion: https://postgr.es/m/759113.1623861959@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/a443c1b2d6a646cf90a8afc193c07ed12a2bf045
Further stabilize postgres_fdw test. The queries involving ft1_nopw don't
stably return the same row anymore. I surmise that an autovacuum hitting "S
1"."T 1" right after the updates introduced by f61db909d/5843659d0 freed some
space, changing where subsequent insertions get stored. It's only by good luck
that these results were stable before, though, since a LIMIT without ORDER BY
isn't well defined, and it's not like we've ever treated that table as
append-only in this test script. Since we only really care whether these
commands succeed or not, just replace "SELECT *"
with "SELECT 1". Report:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2021-06-23%2019%3A52%3A08
https://git.postgresql.org/pg/commitdiff/802177090992511c610804da54a4603d4f50c594
Doc: remove commit f560209c6 from v14 release notes. Now that this has been back-patched, it's no longer a new feature for v14. https://git.postgresql.org/pg/commitdiff/8a80562d732c0da1ddcc9fb88dfb976f4b846577
Remove unnecessary failure cases in RemoveRoleFromObjectPolicy(). It's not really necessary for this function to open or lock the relation associated with the pg_policy entry it's modifying. The error checks it's making on the rel are if anything counterproductive (e.g., if we don't want to allow installation of policies on system catalogs, here is not the place to prevent that). In particular, it seems just wrong to insist on an ownership check. That has the net effect of forcing people to use superuser for DROP OWNED BY, which surely is not an effect we want. Also there is no point in rebuilding the dependencies of the policy expressions, which aren't being changed. Lastly, locking the table also seems counterproductive; it's not helping to prevent race conditions, since we failed to re-read the pg_policy row after acquiring the lock. That means that concurrent DDL would likely result in "tuple concurrently updated/deleted" errors; which is the same behavior this code will produce, with less overhead. Per discussion of bug #17062. Back-patch to all supported versions, as the failure cases this eliminates seem just as undesirable in 9.6 as in HEAD. Discussion: https://postgr.es/m/1573181.1624220108@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5a0f1c8c0193f0dd7fba50c22d96781fa2414007
Remove undesirable libpq dependency on stringinfo.c. Commit c0cb87fbb unwisely introduced a dependency on the StringInfo machinery in fe-connect.c. We must not use that in libpq, because it will do a summary exit(1) if it hits OOM, and that is not appropriate behavior for a general-purpose library. The goal of allowing arbitrary line lengths in service files doesn't seem like it's worth a lot of effort, so revert back to the previous method of using a stack-allocated buffer and failing on buffer overflow. This isn't an exact revert though. I kept that patch's refactoring to have a single exit path, as that seems cleaner than having each error path know what to do to clean up. Also, I made the fixed-size buffer 1024 bytes not 256, just to push off the need for an expandable buffer some more. There is more to do here; in particular the lack of any mechanical check for this type of mistake now seems pretty hazardous. But this fix gets us back to the level of robustness we had in v13, anyway. Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com https://git.postgresql.org/pg/commitdiff/8ec00dc5cd70e0e579e9fbf8661bc46f5ccd8078
Doc: update v14 release notes for revert of commit c0cb87fbb. https://git.postgresql.org/pg/commitdiff/dcffc9ba8a1e0ab1b0a57e9b9d38e3dc9960f83f
Remove memory leaks in isolationtester. specscanner.l leaked a kilobyte of memory per token of the spec file. Apparently somebody thought that the introductory code block would be executed once; but it's once per yylex() call. A couple of functions in isolationtester.c leaked small amounts of memory due to not bothering to free one-time allocations. Might as well improve these so that valgrind gives this program a clean bill of health. Also get rid of an ugly static variable. Coverity complained about one of the one-time leaks, which led me to try valgrind'ing isolationtester, which led to discovery of the larger leak. https://git.postgresql.org/pg/commitdiff/642c0697c96b9c6ba5d194653a329f7820565f01
Michaël Paquier pushed:
Remove forced toast recompression in VACUUM FULL/CLUSTER. The extra checks added by the recompression of toast data introduced in bbe0a81 is proving to have a performance impact on VACUUM or CLUSTER even if no recompression is done. This is more noticeable with more toastable columns that contain non-NULL values. Improvements could be done to make those extra checks less expensive, but that's not material for 14 at this stage, and we are not sure either if the code path of VACUUM FULL/CLUSTER is adapted for this job. Per discussion with several people, including Andres Freund, Robert Haas, Álvaro Herrera, Tom Lane and myself. Discussion: https://postgr.es/m/20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/dbab0c07e5ba1f19a991da2d72972a8fe9a41bda
Improve handling of dropped objects in pg_event_trigger_ddl_commands(). An object found as dropped when digging into the list of objects returned by pg_event_trigger_ddl_commands() could cause a cache lookup error, as the calls grabbing for the object address and the type name would fail if the object was missing. Those lookup errors could be seen with combinations of ALTER TABLE sub-commands involving identity columns. The lookup logic is changed in this code path to get a behavior similar to any other SQL-callable function by ignoring objects that are not found, taking advantage of 2a10fdc. The back-branches are not changed, as they require this commit that is too invasive for stable branches. While on it, add test cases to exercise event triggers with identity columns, and stress more cases with the event ddl_command_end for relations. Author: Sven Klemm, Aleksander Alekseev, Michael Paquier Discussion: https://postgr.es/m/CAMCrgp2R1cEXU53iYKtW6yVEp2_yKUz+z=3-CTrYpPP+xryRtg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2d689babe3cb50dcb29f6ed595a61d56e518c0d8
doc: Apply markup <productname> to OpenSSL more consistently. Author: Daniel Gustafsson Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se https://git.postgresql.org/pg/commitdiff/f80979f659d39e238e95444e6752142799428078
Fix pattern matching logic for logs in TAP tests of pgbench. The logic checking for the format of per-thread logs used grep() with directly "$re", which would cause the test to consider all the logs as a match without caring about their format at all. Using "/$re/" makes grep() perform a regex test, which is what we want here. While on it, improve some of the tests to be more picky with the patterns expected and add more comments to describe the tests. Issue discovered while digging into a separate patch. Author: Fabien Coelho, Michael Paquier Discussion: https://postgr.es/m/YNPsPAUoVDCpPOGk@paquier.xyz Backpatch-through: 11 https://git.postgresql.org/pg/commitdiff/c13585fe9e55813cf9feac67fe7b65d3a78fff92
doc: Move remove_temp_files_after_crash to section for developer options. The main goal of this option is to allow inspecting temporary files for debugging purposes, so moving the parameter there is natural. Oversight in cd91de0. Reported-by: Justin Pryzby Author: Euler Taveira Discussion: https://postgr.es/m/20210612004347.GP16435@telsasoft.com https://git.postgresql.org/pg/commitdiff/797b0fc0b078c7b4c46ef9f2d9e47aa2d98c6c63
Add more debugging information with log checks in TAP tests of pgbench. fairywren is not happy with the pattern checks introduced by c13585f. I am not sure if this outlines a bug in pgbench or if the regex patterns used in the tests are too restrictive for this buildfarm member's environment. This adds more debugging information to show the log entries that do not match with the expected pattern, to help in finding out what's happening. That seems like a good addition in the long-term anyway as that may not be the only issue in this area. Discussion: https://postgr.es/m/YNUad2HvgW+6eXyo@paquier.xyz https://git.postgresql.org/pg/commitdiff/87b2124dfa0782a697ea7b90aff15a6f6117a720
doc: Add acronyms for MITM and SNI. This adds MITM and SNI as acronyms, as the documentation already had them marked up with <acronym>. While on it, make sure to spell man-in-the-middle with dashes consistently, and add acronyms for those new terms where appropriate. Author: Daniel Gustafsson Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se https://git.postgresql.org/pg/commitdiff/15ff5401d1719aaf6c9a47e5abea517cc2bcbaf1
Cleanup some code related to pgbench log checks in TAP tests. This fixes a couple of problems within the so-said code of this commit subject: - Replace the use of open() with slurp_file(), fixing an issue reported by buildfarm member fairywren whose perl installation keep around CRLF characters, causing the matching patterns for the logs to fail. - Remove the eval block, which is not really necessary. This set of issues has come into light after fixing a different issue with c13585fe, and this is wrong since this code has been introduced. Reported-by: Andrew Dunstan, and buildfarm member fairywren Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/0f49303e-7784-b3ee-200b-cbf67be2eb9e@dunslane.net Backpatch-through: 11 https://git.postgresql.org/pg/commitdiff/38ff135d9466c35b506b1049fedef73047907be0
Remove some useless logs from the TAP tests of pgbench. 002_pgbench_no_server was printing some array pointers instead of the actual contents of those arrays for the expected outputs of stdout and stderr for a tested command. This does not add any new information that can help with debugging as the test names allow to track failure locations, if any. This commit simply removes those logs as the rest of the printed information is redundant with command_checks_all(). Per discussion with Andrew Dunstan and Álvaro Herrera. Discussion: https://postgr.es/m/YNXNFaG7IgkzZanD@paquier.xyz Backpatch-through: 11 https://git.postgresql.org/pg/commitdiff/704e1dbd9aa29a0b46c356f1803ad55cbdef2c20
Remove non-existing variable reference in MSVC's Solution.pm. The version string is grabbed from PACKAGE_VERSION in pg_config.h in the MSVC build since 8f4fb4c6, but an error message referenced a variable that existed before that. This had no consequences except if one messes up enough with the version number of the build. Author: Anton Voloshin Discussion: https://postgr.es/m/af79ee1b-9962-b299-98e1-f90a289e19e6@postgrespro.ru Backpatch-through: 13 https://git.postgresql.org/pg/commitdiff/d5a2c413fcdd187dc16c4fab16610af7d4849cc1
Bruce Momjian pushed:
doc: add PG 14 relnote item about array function references. User-defined objects that reference some built-in array functions will need to be recreated in PG 14. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20210608225618.GR16435@telsasoft.com https://git.postgresql.org/pg/commitdiff/25dfb5a831a1b8a83a8a68453b4bbe38a5ef737e
doc: PG 14 relnote updates. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20210612034551.GU16435@telsasoft.com https://git.postgresql.org/pg/commitdiff/a2559d4093725592a3fd5da8a4c7ac7c883115a0
doc: PG 14 relnotes fixes. Items related to logical replication attribution and BRIN indexes Reported-by: Tomas Vondra, John Naylor Discussion: https://postgr.es/m/0db66294-a668-2caa-2b5e-a8db60b30662@enterprisedb.com, CAFBsxsH21KnteYdk33F1oZu2O726NSD6_XBq51Tn0jytsA1AnA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/86b222b09071d3918c5c55b164d22b2236d3f872
doc: add mention of +4GB windows file handling in PG14 relnotes. Reported-by: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoCTHyouoGv-xt1qNjjvPbGMErLi0AJncByTvr66Nq7j8g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/90855908b751d40f67352fa0252e0fcdaa7e317b
doc: adjust PG 14 relnotes to be current. https://git.postgresql.org/pg/commitdiff/69a58bfe4ab05567a8fab8bdce7f3095ed06b99c
Álvaro Herrera pushed:
Fix logic bug in 1632ea43682f. I overlooked that one condition was logically inverted. The fix is a little bit more involved than simply negating the condition, to make the code easier to read. Fix some outdated comments left by the same commit, while at it. Author: Masahiko Sawada sawada.mshk@gmail.com Author: Álvaro Herrera alvherre@alvh.no-ip.org Reviewed-by: Amit Kapila amit.kapila16@gmail.com Discussion: https://postgr.es/m/YMRlmB3/lZw8YBH+@paquier.xyz https://git.postgresql.org/pg/commitdiff/33c509956704e1d918077b51ccd954f2e201a8f5
Add test case for obsoleting slot with active walsender. The code to signal a running walsender when its reserved WAL size grows too large is completely uncovered before this commit; this adds coverage for that case. This test involves sending SIGSTOP to walsender and walreceiver and running a checkpoint while advancing WAL, then sending SIGCONT. There's no precedent for this coding in Perl tests, and my reading of relevant manpages says it's likely to fail on Windows. Because of this, this test is always skipped on that platform. Author: Álvaro Herrera alvherre@alvh.no-ip.org Discussion: https://postgr.es/m/202106102202.mjw4huiix7lo@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/09126984a2631db8dd6299f23954e0dede69735f
Revert "Add test case for obsoleting slot with active walsender". This reverts commit 09126984a263; the test case added there failed once in circumstances that remain mysterious. It seems better to remove the test for now so that 14beta2 doesn't have random failures built in. https://git.postgresql.org/pg/commitdiff/96795176810b979a2bf1f4563bdcb161679d5b95
Add test case for obsoleting slot with active walsender, take 2. The code to signal a running walsender when its reserved WAL size grows too large is completely uncovered before this commit; this adds coverage for that case. This test involves sending SIGSTOP to walsender and walreceiver, then advancing enough WAL for a checkpoint to trigger, then sending SIGCONT. There's no precedent for STOP signalling in Perl tests, and my reading of relevant manpages says it's likely to fail on Windows. Because of this, this test is always skipped on that platform. This version fixes a couple of rarely hit race conditions in the previous attempt 09126984a263; most notably, both LOG string searches are loops, not just the second one; we acquire the start-of-log position before STOP-signalling; and reference the correct process name in the test description. All per Tom Lane. Author: Álvaro Herrera alvherre@alvh.no-ip.org Discussion: https://postgr.es/m/202106102202.mjw4huiix7lo@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/24043c27b46f873211177e3460ab09dc011802a5
Noah Misch pushed:
Remove pg_wait_for_backend_termination(). It was unable to wait on a backend that had already left the procarray. Users tolerant of that limitation can poll pg_stat_activity. Other users can employ the "timeout" argument of pg_terminate_backend(). Reviewed by Bharath Rupireddy. Discussion: https://postgr.es/m/20210605013236.GA208701@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/5f1df62a459b51ab3bb625a0ee5e655429254257
Copy-edit text for the pg_terminate_backend() "timeout" parameter. Revert the pg_description entry to its v13 form, since those messages usually remain shorter and don't discuss individual parameters. No catversion bump, since pg_description content does not impair backend compatibility or application compatibility. Justin Pryzby Discussion: https://postgr.es/m/20210612182743.GY16435@telsasoft.com https://git.postgresql.org/pg/commitdiff/0aac73e6a2602696d23aa7a9686204965f9093dc
Finish rename of PQtraceSetFlags() to PQsetTraceFlags(). Jie Zhang Discussion: https://postgr.es/m/TYWPR01MB767844835390EDD8DB276D75F90A9@TYWPR01MB7678.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/047a259e35b9dde2dad5fd0e5d5d784bb327b848
Amit Kapila pushed:
Fix decoding of speculative aborts. During decoding for speculative inserts, we were relying for cleaning toast hash on confirmation records or next change records. But that could lead to multiple problems (a) memory leak if there is neither a confirmation record nor any other record after toast insertion for a speculative insert in the transaction, (b) error and assertion failures if the next operation is not an insert/update on the same table. The fix is to start queuing spec abort change and clean up toast hash and change record during its processing. Currently, we are queuing the spec aborts for both toast and main table even though we perform cleanup while processing the main table's spec abort record. Later, if we have a way to distinguish between the spec abort record of toast and the main table, we can avoid queuing the change for spec aborts of toast tables. Reported-by: Ashutosh Bapat Author: Dilip Kumar Reviewed-by: Amit Kapila Backpatch-through: 9.6, where it was introduced Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4daa140a2f50e9a160bc180c3997ee13c7aabf9e
Document a few caveats in synchronous logical replication. In a synchronous logical setup, locking [user] catalog tables can cause deadlock. This is because logical decoding of transactions can lock catalog tables to access them so exclusively locking those in transactions can lead to deadlock. To avoid this users must refrain from having exclusive locks on catalog tables. Author: Takamichi Osumi Reviewed-by: Vignesh C, Amit Kapila Backpatch-through: 9.6 Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/3cb828dbe26087e7754f49f3cfe3ed036d5af439
Handle no replica identity index case in RelationGetIdentityKeyBitmap. Commit e7eea52b2d has introduced a new function RelationGetIdentityKeyBitmap which omits to handle the case where there is no replica identity index on a relation. Author: Mark Dilger Reviewed-by: Takamichi Osumi, Amit Kapila Discussion: https://www.postgresql.org/message-id/4C99A862-69C8-431F-960A-81B1151F1B89@enterprisedb.com https://git.postgresql.org/pg/commitdiff/2731ce1bd550d08f3fdd7bcb1497af4b95170976
Doc: Update caveats in synchronous logical replication. Reported-by: Simon Riggs Author: Takamichi Osumi Reviewed-by: Amit Kapila Backpatch-through: 9.6 Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/c66fb78ebb4f473bb4fd8773de3cda9339e14f81
Doc: Update logical replication message formats. Commits 9de77b5453 and ac4645c015 missed to update the logical replication message formats section in the docs. Author: Brar Piening Reviewed-by: Amit Kapila Discussion: https://www.postgresql.org/message-id/cc70956c-e578-e54f-49e6-b5d68c89576f@gmx.de https://git.postgresql.org/pg/commitdiff/f08722cf83ab1fabee948a4e5754bf6236ad700b
Doc: Fix minor formatting issue in logicaldecoding.sgml. Author: Guillaume Lelarge Discussion: https://www.postgresql.org/message-id/CAECtzeXf3_oZoU6mgFCOy5+pDZ5n4XtH0Da4a5n_KacraVWiHQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/847c62ee76cbc237b3a204ca94b1b12811d698e3
Alexander Korotkov pushed:
Support for unnest(multirange) and cast multirange as an array of ranges. It has been spotted that multiranges lack of ability to decompose them into individual ranges. Subscription and proper expanded object representation require substantial work, and it's too late for v14. This commit provides the implementation of unnest(multirange) and cast multirange as an array of ranges, which is quite trivial. unnest(multirange) is defined as a polymorphic procedure. The catalog description of the cast underlying procedure is duplicated for each multirange type because we don't have anyrangearray polymorphic type to use here. Catversion is bumped. Reported-by: Jonathan S. Katz Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org Author: Alexander Korotkov Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu https://git.postgresql.org/pg/commitdiff/29854ee8d1ca4a46adb7e84deb17e6fb18e531cc
Add missing type name "multirange" in docs chapter title. Discussion: https://postgr.es/m/CAFj8pRDioOxiJgmgw9TqQqZ3CxnJC4P5B2Oospf2eMgAjJuewA%40mail.gmail.com Author: Pavel Stehule, Alexander Korotkov Reviewed-by: Justin Pryzby, Tom Lane https://git.postgresql.org/pg/commitdiff/ad2da246c69dd5ec55764d4b6066f3b0c0d24ca2
Revert 29854ee8d1 due to buildfarm failures. Reported-by: Tom Lane Discussion: https://postgr.es/m/CAPpHfdvcnw3x7jdV3r52p4%3D5S4WUxBCzcQKB3JukQHoicv1LSQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/817bb0a7d1e02df4643d37304aed8574cf43f629
Peter Geoghegan pushed:
Remove unneeded field from VACUUM state. Bugfix commit 5fc89376 effectively made the lock_waiter_detected field from vacuumlazy.c's global state struct into private state owned by lazy_truncate_heap(). Finish this off by replacing the struct field with a local variable. https://git.postgresql.org/pg/commitdiff/958cfbcf2dd338e3179c2d8a35f48bde020eba60
Support disabling index bypassing by VACUUM. Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding reloption): make it into a ternary style boolean parameter. It now exposes a third option, "auto". The "auto" option (which is now the default) enables the "bypass index vacuuming" optimization added by commit 1e55e7d1. "VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM simply do any required index vacuuming, regardless of how few dead tuples are encountered during the first scan of the target heap relation (unless there are exactly zero). This gives users a way of opting out of the "bypass index vacuuming" optimization, if for whatever reason that proves necessary. It is also expected to be used by PostgreSQL developers as a testing option from time to time. "VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it forcibly disables both index vacuuming and index cleanup. It's not expected to be used much in PostgreSQL
The failsafe mechanism added by commit 1e55e7d1 addresses the same problem in a simpler way. INDEX_CLEANUP can now be thought of as a testing and compatibility option. Author: Peter Geoghegan pg@bowt.ie Reviewed-By: Masahiko Sawada sawada.mshk@gmail.com Reviewed-By: Justin Pryzby pryzby@telsasoft.com Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3499df0dee8c4ea51d264a674df5b5e31991319a
Remove overzealous VACUUM failsafe assertions. The failsafe can trigger when index processing is already disabled. This can happen when VACUUM's INDEX_CLEANUP parameter is "off" and the failsafe happens to trigger. Remove assertions that assume that index processing is directly tied to the failsafe. Oversight in commit c242baa4, which made it possible for the failsafe to trigger in a two-pass strategy VACUUM that has yet to make its first call to lazy_vacuum_all_indexes(). https://git.postgresql.org/pg/commitdiff/e8f201ab82be234b2f103234cf9f262f9afeaeba
Add list of ignorable pgindent commits for git-blame. Add a .git-blame-ignore-revs file with a list of pgindent, pgperlyidy, and reformat-dat-files commit hashes. Postgres hackers that configure git to use the ignore file will get git-blame output that avoids attributing line changes to the ignored indent commits. This makes git-blame output much easier to work with in practice. Author: Peter Geoghegan pg@bowt.ie Reviewed-By: Tom Lane tgl@sss.pgh.pa.us Discussion: https://postgr.es/m/CAH2-Wz=cVh3GHTP6SdLU-Gnmt2zRdF8vZkcrFdSzXQ=WhbWm9Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8e638845ff6bb255ad1dea15831089a234535391
Andrew Dunstan pushed:
Further refinement of stuck_on_old_timeline recovery test. TestLib::perl2host can take a file argument as well as a directory argument, so that code becomes substantially simpler. Also add comments on why we're using forward slashes, and why we're setting PERL_BADLANG=0. Discussion: https://postgr.es/m/e9947bcd-20ee-027c-f0fe-01f736b7e345@dunslane.net https://git.postgresql.org/pg/commitdiff/54a5ed22016940d7ad5060ed62d23473924756a1
Don't set a fast default for anything but a plain table. The fast default code added in Release 11 omitted to check that the table a fast default was being added to was a plain table. Thus one could be added to a foreign table, which predicably blows up. Here we perform that check. In addition, on the back branches, since some of these might have escaped into the wild, if we encounter a missing value for an attribute of something other than a plain table we ignore it. Fixes bug #17056 Backpatch to release 11, Reviewed by: Andres Freund, Álvaro Herrera and Tom Lane https://git.postgresql.org/pg/commitdiff/0a4efdc7ebf2584257b166c87e82797eb92815b5
Heikki Linnakangas pushed:
Fix outdated comment that talked about seek position of WAL file. Since commit c24dcd0cfd, we have been using pg_pread() to read the WAL file, which doesn't change the seek position (unless we fall back to the implementation in src/port/pread.c). Update comment accordingly. Backpatch-through: 12, where we started to use pg_pread() https://git.postgresql.org/pg/commitdiff/d0303bc8d2670d11c9df9220aa08a2c33529e100
Tidy up GetMultiXactIdMembers()'s behavior on error. One of the error paths
left *members
uninitialized. That's not a live bug, because most callers don't
look at *members
when the function returns -1, but let's be tidy. One caller,
in heap_lock_tuple(), does "if (members != NULL) pfree(members)", but AFAICS
it never passes an invalid 'multi' value so it should not reach that error
case. The callers are also a bit inconsistent in their expectations.
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others pfree()
it if "nmembers >= 0", and others if "nmembers > 0". That's not a live bug
either, because the function should never return 0, but add an Assert for that
to make it more clear. I left the callers alone for now. I also moved the
line where we set *nmembers
. It wasn't wrong before, but I like to do that
right next to the 'return' statement, to make it clear that it's always set on
return. Also remove one unreachable return statement after ereport(ERROR),
for brevity and for consistency with the similar if-block right after it.
Author: Greg Nancarrow with the additional changes by me Backpatch-through:
9.6, all supported versions
https://git.postgresql.org/pg/commitdiff/d24c5658a80c8f5037e9e1948de311d3f3350f12
Prevent race condition while reading relmapper file. Contrary to the comment here, POSIX does not guarantee atomicity of a read(), if another process calls write() concurrently. Or at least Linux does not. Add locking to load_relmap_file() to avoid the race condition. Fixes bug #17064. Thanks to Alexander Lakhin for the report and test case. Backpatch-through: 9.6, all supported versions. Discussion: https://www.postgresql.org/message-id/17064-bb0d7904ef72add3@postgresql.org https://git.postgresql.org/pg/commitdiff/b6d8d2073f228d9f7198f1f9826d8f6ab643c219
Another fix to relmapper race condition. In previous commit, I missed that relmap_redo() was also not acquiring the RelationMappingLock. Thanks to Thomas Munro for pointing that out. Backpatch-through: 9.6, like previous commit. Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/9b8ed0f52bffceaccf6fa650ffe482e7da20fbf2
Tomáš Vondra pushed:
Fujii Masao pushed:
Peter Eisentraut pushed:
amcheck: Fix code comments. Code comments were claiming that verify_heapam() was checking privileges on the relation it was operating on, but it didn't actually do that. Perhaps earlier versions of the patch did that, but now the access is regulated by privileges on the function. Remove the wrong comments. https://git.postgresql.org/pg/commitdiff/97b7134186490b36e01efc9d2feaf7038c666457
Translation updates. Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 70796ae860c444c764bb591c885f22cac1c168ec https://git.postgresql.org/pg/commitdiff/a7bb0ce58f56ee8907c3f49c52d99f502536c796
Remove redundant variable pageSize in gistinitpage. In gistinitpage, pageSize variable looks redundant, instead just pass BLCKSZ. This will be consistent with its peers BloomInitPage, brin_page_init and SpGistInitPage. Author: Bharath Rupireddy bharath.rupireddy@enterprisedb.com Discussion: https://www.postgresql.org/message-id/flat/CALj2ACWj=V1k5591eeZK2sOg2FYuBUp6azFO8tMkBtGfXf8PMQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a60c4c5c1a99746485123ae93fbd3e58c78e5d62
doc: Change reloption data type spelling for consistency. Use "floating point" rather than "float4", like everywhere else in this context. Author: Shinya11.Kato@nttdata.com Discussion: https://www.postgresql.org/message-id/flat/TYAPR01MB28965989AF84B57FC351B97BC40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/63e6d05bf34da58eef7cd1ed461b9c8315177a38
Fixes in ALTER SUBSCRIPTION DROP PUBLICATION code. ALTER SUBSCRIPTION DROP PUBLICATION does not actually support copy_data option, so remove it from tab completion. Also, reword the error message that is thrown when all the publications from a subscription are specified to be dropped. Also, made few doc and cosmetic adjustments. Author: Vignesh C vignesh21@gmail.com Reviewed-by: Bharath Rupireddy bharath.rupireddy@enterprisedb.com Reviewed-by: Japin Li japinli@hotmail.com Discussion: https://www.postgresql.org/message-id/flat/CALDaNm21RwsDzs4xj14ApteAF7auyyomHNnp+NEL-sH8m-jMvQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e59d428f34297cd0eb67e3b4e4b8c8bc58504921
Put option listing back into alphabetical order. https://git.postgresql.org/pg/commitdiff/3af10943ce21450e299b3915b9cad47cd90369e9
Error message refactoring. Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes. https://git.postgresql.org/pg/commitdiff/c302a6139072fed9410204fa9e751d95930e05ff
David Rowley pushed:
Andres Freund pushed:
Joe Conway pushed:
Thomas Munro pushed:
Nitin Jadhav sent in another revision of a patch to make a way to track the progress of the operations performed during the startup process.
Yuzuko Hosoya sent in a patch to control whether autoanalyze runs for partition operations via new GUCs autovacuum_analyze_attach_partition, autovacuum_analyze_detach_partition, and autovacuum_analyze_drop_partition.
Peter Eisentraut sent in a patch to add an index OID macro argument to DECLARE_INDEX. Instead of defining symbols such as AmOidIndexId explicitly, include them as an argument of DECLARE_INDEX() and have genbki.pl generate the way as the table OID symbols from the CATALOG() declaration
Filip Gospodinov sent in a patch to intended to fix a bug that manifested as the shipped pkg-config file is broken for statically linking libpq because libpgcommon and libpgport are missing. The fix adds those two missing private dependencies.
Heikki Linnakangas sent in another revision of a patch to split xlog.c into xlog.c and xlogrecovery.c. This moves the functions related to performing WAL recovery into the new xlogrecovery.c source file, leaving xlog.c responsible for maintaining the WAL buffers, coordinating the startup and switch from recovery to normal operations, and other miscellaneous stuff that have always been in xlog.c
Greg Nancarrow sent in two revisions of a patch to remove the useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values.
Peter Geoghegan sent in three revisions of a patch to add a list of ignorable pgindent commits for "git blame".
David Rowley sent in another revision of a patch to add a new hash table type which has stable pointers, and use same to speed up SMgr.
Peter Smith and Ajin Cherian traded patches to add an option to support prepared transactions to built-in logical replication.
Daniel Gustafsson and Michaël Paquier traded patches to document some SSL/TLS related acronyms, and replace usage of SSL with SSL/TLS, the latter being more accurate and up to date.
Simon Riggs sent in three revisions of a patch to add a documentation chapter on hash indexes.
Atsushi Torikoshi sent in another revision of a patch to add a function to log the complete query string and its plan for the query currently running on the backend with the specified process ID.
Li Japin sent in a patch to make a minor code beautification in RelationGetIdentityKeyBitmap.
Bertrand Drouvot sent in another revision of a patch to enable minimal logical decoding on standbys.
Alexander Pyhalov sent in another revision of a patch to allow pushing CASE expressions to foreign servers.
Peter Eisentraut sent in a patch to Make the Unicode makefile more parallel-safe, Make UCS_to_most.pl process encodings in sorted order, remove some whitespace in generated C output to get it in line with the coding style of the rest of the project, simplify the code-generation code, and fix indentation in generated output.
Maxim Orlov sent in another revision of a patch to fix parallel worker failed assertion and coredump.
Vigneshwaran C sent in two more revisions of a patch to add schema level support for PUBLICATIONs.
Mike Fiedler sent in a patch to emit the namespace in post-copy output.
Emre Hasegeli sent in a patch to decouple operator classes from index access methods.
Jacob Champion sent in two revisions of a patch to decouple the SASL framework from the SCRAM code, as it may be useful separately.
Yugo Nagata sent in another revision of a patch to address some Pgbench errors by using the Variables structure for client variables. This is most important when it is used to reset client variables during the repeating of transactions after serialization/deadlock failures. Don't allocate Variable structs one by one. Instead, add a constant margin each time it overflows. Also included, a fix for pgbench errors and serialization/deadlock retries.
Jacob Champion, Michaël Paquier, and Tom Lane traded patches to make it possible to use jsonapi with libpq.
Gurjeet Singh sent in a patch to add automatic notification for top transaction IDs.
Haiying Tang sent in another revision of a patch to support tab completion with a query result for upper case inputs in psql.
Peter Eisentraut sent in a patch to make genbki error handling more useful by counting the errors and error out at the end instead of just writing warnings for invalid cross-catalog lookups.
Daniel Gustafsson sent in another revision of a patch to support NSS as a TLS backend for libpq.
Andrey V. Lepikhov sent in a patch to inform genericcostestimate()'s index selectivity value of the fact that in the case of an unique one-row btree index, scan only one row can be returned.
Tomáš Vondra sent in another revision of a patch to make it possible to replicate sequences in logical decoding.
Ranier Vilela sent in a patch to fix an uninitialized copy_data var in src/backend/commands/subscriptioncmds.c.
Peter Eisentraut sent in another revision of a patch to improve error messages about mismatching relkind by making the primary error message shorter and saying more directly that what was attempted is not possible.
Peter Eisentraut sent in a patch to add tests for UNBOUNDED syntax ambiguity.
Simon Riggs sent in a patch to make pgbench use COPY FREEZE.
Justin Pryzby sent in a patch to avoid double parentheses, and fix a comment in tablefunc.c to refer to the correct comment.
Craig Ringer sent in a patch to add some more PGDLLIMPORTs to expose some of the things heretofore unavailable on Windows.
Amit Kapila sent in a patch to allow streaming the changes after speculative aborts.
Hayato Kuroda sent in a patch to make ECPG's new DECLARE STATEMENT work for DEALLOCATE and DESCRIBE.
Bruce Momjian sent in another revision of a patch to implement cluster file encryption.
Jie Zhang sent in a patch to bring the generated sample postgresql.conf into
line with what's actually the default for shared_buffers
.
Richard Guo sent in a patch to use each rel as both outer and inner for anti joins.
Tom Lane sent in a patch to prevent any calls of abort() or exit() from inside libpq.
Alexander Korotkov sent in a patch to fix some small inconsistencies in the catalog definition of multirange operators.
Julien Rouhaud sent in another revision of a patch to preserve param location when generating a const node.
Andrey Borodin sent in another revision of a patch to reorganize the pglz compression code.
Julien Rouhaud and Ranier Vilela traded patches to add a pg_get_query_def() to deparse and print a rewritten SQL statement.
Tomáš Vondra sent in a PoC patch to do cardinality estimation using runtime sampling.