aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Fix incorrect comment about nbtree WAL record.Peter Geoghegan2023-04-17
| | | | | | | The nbtree VACUUM WAL record stores its page offset number payload in blk 0 (just like the closely related nbtree DELETE WAL record). Commit ebd551f5 fixed a similar issue with the DELETE WAL record, but missed this one.
* Further cleanup of autoconf output files for GSSAPI changes.Tom Lane2023-04-17
| | | | | | | | Running autoheader was missed in f7431bca8. This is cosmetic since we aren't using these HAVE_ symbols, but let's get everything in sync while we're looking at this. Discussion: https://postgr.es/m/2422362.1681741814@sss.pgh.pa.us
* Update configure for ab969a376Stephen Frost2023-04-17
| | | | | | | Commit ab969a376 updated configure.ac but neglected to update the actual configure script. Fix that. Pointed out by Tom Lane
* doc: Add additional SQL features codes from SQL:2023Peter Eisentraut2023-04-17
| | | | These were mysteriously omitted in c9f57541d9.
* Update Kerberos/GSSAPI configure/meson checkStephen Frost2023-04-17
| | | | | | | Instead of checking for the much older gss_init_sec_context, check for gss_store_cred_into which was added in MIT Kerberos 1.11 (circa 2012). Discussion: https://postgr.es/m/2313469.1681695223%40sss.pgh.pa.us
* Put new command-line option into sensible order in help outputPeter Eisentraut2023-04-17
| | | | | | | We have two existing conventions for long options: either alphabetical among short options, or all long options after all the short options. But the convention apparently used here, next to a functionally related option, is not one of them.
* Doc: remove notes about the version vacuumdb options are valid fromDavid Rowley2023-04-17
| | | | | | | | | | | | | | | | | | | | Here we remove the notes which mention which version the given vacuumdb option is available from. There are now 11 of these notes and they're both quite untidy and take up far more space than they seem to be worth. On running a print preview of the compiled HTML, removing these notes saves about 1 A4 page (~20% less space). If people need to see which options are available on older versions, then consulting the documents for that version seems like a good idea. In any case, when using newer vacuumdb versions on older servers, the user will receive an error if they try to use an unsupported option. Additionally, 3 of the notes are warning about the option only being available from PostgreSQL 9.6 and later. That version's support ended 2.5 years ago. So, it's quite clear that the value of these notes diminishes over time. Discussion: https://postgr.es/m/CAApHDvrCQn6tupx2R67VL9RP1Qy4dDuWKRvt4jaB0vk2akQchw@mail.gmail.com
* Ensure result of an aggregate's finalfunc is made read-only.Tom Lane2023-04-16
| | | | | | | | | | | | | | | The finalfunc might return a read-write expanded object. If we de-duplicate multiple call sites for the aggregate, any function(s) receiving the aggregate result earlier could alter or destroy the value that reaches the ones called later. This is a brown-paper-bag bug in commit 42b746d4c, because we actually considered the need for read-only-ness but failed to realize that it applied to the case with a finalfunc as well as the case without. Per report from Justin Pryzby. New error in HEAD, no need for back-patch. Discussion: https://postgr.es/m/ZDm5TuKsh3tzoEjz@telsasoft.com
* Avoid using non-ASCII commentary in daitch_mokotoff.c.Tom Lane2023-04-16
| | | | | | | | | | | | | Commit d6b5dee42 failed to suppress that warning from MSVC, so let's just get rid of all non-ASCII glyphs in the comments. The comment for iso8859_1_to_ascii_upper[] is not essential, and the other cases can be handled by spelling out the Unicode character names. (I'm now really in the dark as to why MSVC doesn't complain about predicate.c's comment. But whatever.) Discussion: https://postgr.es/m/1546512.1681495035@sss.pgh.pa.us
* Doc: add note about --buffer-usage-limit being v16 onwardsDavid Rowley2023-04-16
| | | | | | Other vacuumdb options seem to have notes about which version they're available from, so let's follow this trend for the newly added --buffer-usage-limit option.
* Improve VACUUM/ANALYZE BUFFER_USAGE_LIMIT docsDavid Rowley2023-04-16
| | | | | | | | | | | | | | | | | | | This addresses various deficiencies in the documentation for VACUUM and ANALYZE's BUFFER_USEAGE_LIMIT docs. Here we declare "size" in the syntax synopsis for VACUUM and ANALYZE's BUFFER_USAGE_LIMIT option and then define exactly what values can be specified for it in the section for that below. Also, fix the incorrect ordering of vacuumdb options both in the documents and in vacuumdb's --help output. These should be in alphabetical order. In passing also add the minimum/maximum range for the BUFFER_USAGE_LIMIT option. These will also serve as example values that can be modified and used. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/16845cb1-b228-e157-f293-5892bced9253@enterprisedb.com
* Fix assignment to array of domain over composite, redux.Tom Lane2023-04-15
| | | | | | | | | | | | | | | | Commit 3e310d837 taught isAssignmentIndirectionExpr() to look through CoerceToDomain nodes. That's not sufficient, because since commit 04fe805a1 it's been possible for the planner to simplify CoerceToDomain to RelabelType when the domain has no constraints to enforce. So we need to look through RelabelType too. Per bug #17897 from Alexander Lakhin. Although 3e310d837 was back-patched to v11, it seems sufficient to apply this change to v12 and later, since 04fe805a1 came in in v12. Dmitry Dolgov Discussion: https://postgr.es/m/17897-4216c546c3874044@postgresql.org
* Remove some non-ASCII symbols from a comment.Tom Lane2023-04-15
| | | | | | | | | | | | | | | | | | | | Buildfarm member hamerkop is unhappy that daitch_mokotoff.c "contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss". There are a lot of non-ASCII characters in comments, but I do not see any outside a comment, so this is just cosmetic. Nonetheless the warning is fairly scary and people might waste time trying to understand the cause, so we ought to silence it. We have only one other occurrence of a non-ASCII character in .c or .h files in the tree: predicate.c mentions "Uwe Röhm". It's far from clear why hamerkop isn't complaining about that too; but it isn't, so maybe there is some special provision for accented Roman letters. We can remove the non-letter symbols from the comment for iso8859_1_to_ascii_upper without any real loss of usefulness, so let's try that first to see if it silences the warning. Discussion: https://postgr.es/m/1546512.1681495035@sss.pgh.pa.us
* Adjust Valgrind macro usage to protect chunk headersDavid Rowley2023-04-15
| | | | | | | | | | | | | | Prior to this commit we only ever protected MemoryChunk's requested_size field with Valgrind NOACCESS. This means that if the hdrmask field is ever accessed accidentally then we're not going to get any warnings from Valgrind about it. Valgrind would have warned us about the problem fixed in 92957ed98 had we already been doing this. Per suggestion from Tom Lane Reviewed-by: Richard Guo Discussion: https://postgr.es/m/1650235.1672694719@sss.pgh.pa.us Discussion: https://postgr.es/m/CAApHDvr=FZNGbj252Z6M9BSFKoq6BMxgkQ2yEAGUYoo7RquqZg@mail.gmail.com
* Support RBM_ZERO_AND_CLEANUP_LOCK in ExtendBufferedRelTo(), add testsAndres Freund2023-04-14
| | | | | | | | | | | | | | | | | | | For some reason I had not implemented RBM_ZERO_AND_CLEANUP_LOCK support in ExtendBufferedRelTo(), likely thinking it not being reachable. But it is reachable, e.g. when replaying a WAL record for a page in a relation that subsequently is truncated (likely only reachable when doing crash recovery or PITR, not during ongoing streaming replication). As now all of the RBM_* modes are supported, remove assertions checking mode. As we had no test coverage for this scenario, add a new TAP test. There's plenty more that ought to be tested in this area... Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Reported-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/392271.1681238924%40sss.pgh.pa.us Discussion: https://postgr.es/m/0b5eb82b-cb99-e0a4-b932-3dc60e2e3926@gmail.com
* NULL is not an ideal way to spell bool "false".Tom Lane2023-04-14
| | | | Thinko in commit 6633cfb21, detected by buildfarm member hamerkop.
* doc: PQinitOpenSSL and PQinitSSL are obsolete in OpenSSL 1.1.0+Daniel Gustafsson2023-04-14
| | | | | | | | | | | | | | Starting with OpenSSL 1.1.0 there is no need to call PQinitOpenSSL or PQinitSSL to avoid duplicate initialization of OpenSSL. Add a note to the documentation to explain this. Backpatch to all supported versions as older OpenSSL versions are equally likely to be used for all branches. Reported-by: Sebastien Flaesch <sebastien.flaesch@4js.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/DBAP191MB12895BFFEC4B5FE0460D0F2FB0459@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM Backpatch-through: 11, all supported versions
* Fix whitespacePeter Eisentraut2023-04-14
|
* Add missing source files to nls.mkPeter Eisentraut2023-04-14
|
* Fix incorrect partition pruning logic for boolean partitioned tablesDavid Rowley2023-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The partition pruning logic assumed that "b IS NOT true" was exactly the same as "b IS FALSE". This is not the case when considering NULL values. Fix this so we correctly include any partition which could hold NULL values for the NOT case. Additionally, this fixes a bug in the partition pruning code which handles partitioned tables partitioned like ((NOT boolcol)). This is a seemingly unlikely schema design, and it was untested and also broken. Here we add tests for the ((NOT boolcol)) case and insert some actual data into those tables and verify we do get the correct rows back when running queries. I've also adjusted the existing boolpart tests to include some data and verify we get the correct results too. Both the bugs being fixed here could lead to incorrect query results with fewer rows being returned than expected. No additional rows could have been returned accidentally. In passing, remove needless ternary expression. It's more simple just to pass !is_not_clause to makeBoolConst(). It makes sense to do this so the code is consistent with the bug fix in the "else if" condition just below. David Kimura did submit a patch to fix the first of the issues here, but that's not what's being committed here. Reported-by: David Kimura Reviewed-by: Richard Guo, David Kimura Discussion: https://postgr.es/m/CAHnPFjQ5qxs6J_p+g8=ww7GQvfn71_JE+Tygj0S7RdRci1uwPw@mail.gmail.com Backpatch-through: 11, all supported versions
* doc: Fix some grammar for logical decoding description and functionsMichael Paquier2023-04-14
| | | | | | | | | This documentation is has been added for the support of logical decoding on standbys. Some markups were missing, hence add some where required. Author: Thom Brown Reviewed-by: Justin Pryzby, Daniel Gustafsson Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com
* Fix PHJ match bit initialization.Thomas Munro2023-04-14
| | | | | | | | | | | | | | | | | Hash join tuples reuse the HOT status bit to indicate match status during hash join execution. Correct reuse requires clearing the bit in all tuples. Serial hash join and parallel multi-batch hash join do so upon inserting the tuple into the hashtable. Single batch parallel hash join and batch 0 of unexpected multi-batch hash joins forgot to do this. It hadn't come up before because hashtable tuple match bits are only used for right and full outer joins and parallel ROJ and FOJ were unsupported. 11c2d6fdf5 introduced support for parallel ROJ/FOJ but neglected to ensure the match bits were reset. Author: Melanie Plageman <melanieplageman@gmail.com> Reported-by: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/flat/CAMbWs48Nde1Mv%3DBJv6_vXmRKHMuHZm2Q_g4F6Z3_pn%2B3EV6BGQ%40mail.gmail.com
* Remove code in charge of freeing regexps generation by Lab.cMichael Paquier2023-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | bea3d7e has redesigned the regexp engine so as all the allocations go through palloc() with a dedicated memory context. hba.c had to cope with the past memory management logic by going through all the HBA and ident lines generated, then directly free all the regexps found in AuthTokens to ensure that no leaks would happen. Such leaks could happen for example in the postmaster after a SIGHUP, in the event of an HBA and/or ident reload failure where all the new content parsed must be discarded, including all the regexps that may have been compiled. Now that regexps are palloc()'d in their own memory context, MemoryContextDelete() is enough to ensure that all the compiled regexps are properly gone. Simplifying this logic in hba.c has the effect to only remove code. Most of it is new in v16, except the part for regexps compiled in ident entries for the system username, so doing this cleanup now rather than when v17 opens for business will reduce future diffs with the upcoming REL_16_STABLE. Some comments were incorrect since bea3d7e, now fixed to reflect the reality. Reviewed-by: Bertrand Drouvot, Álvaro Herrera Discussion: https://postgr.es/m/ZDdJ289Ky2qEj4h+@paquier.xyz
* Remove old GUC name mapping for "force_parallel_mode"David Rowley2023-04-14
| | | | | | | | | | | | | | | | This GUC was renamed to debug_parallel_query in 5352ca22e. That commit added an entry into map_old_guc_names[] to allow the old name still to work. That was done to allow a transition time where the buildfarm configs could be swapped over to use debug_parallel_query instead. That work is now complete. Here we remove the old name with the intention of breaking any user code which is using force_parallel_query. As mentioned in the commit message for 5352ca22e, it appeared many users were misled into thinking that setting this GUC was doing something useful for them to make queries run more quickly. Discussion: https://postgr.es/m/CAApHDvoR7EOz7Tvyzrd18FO-Dw2Cp4Uyq25TEWguK+XyCJtzOw@mail.gmail.com
* Update Unicode data to CLDR 43Peter Eisentraut2023-04-13
| | | | No actual changes result.
* Harmonize some more function parameter names.Peter Geoghegan2023-04-13
| | | | | | | | | | | | | | Make sure that function declarations use names that exactly match the corresponding names from function definitions in a few places. These inconsistencies were all introduced relatively recently, after the code base had parameter name mismatches fixed in bulk (see commits starting with commits 4274dc22 and 035ce1fe). pg_bsd_indent still has a couple of similar inconsistencies, which I (pgeoghegan) have left untouched for now. Like all earlier commits that cleaned up function parameter names, this commit was written with help from clang-tidy.
* Explicitly require MIT Kerberos for GSSAPIStephen Frost2023-04-13
| | | | | | | | | | WHen building with GSSAPI support, explicitly require MIT Kerberos and check for gssapi_ext.h in configure.ac and meson.build. Also add documentation explicitly stating that we now require MIT Kerberos when building with GSSAPI support. Reveiwed by: Johnathan Katz Discussion: https://postgr.es/m/abcc73d0-acf7-6896-e0dc-f5bc12a61bb1@postgresql.org
* De-Revert "Add support for Kerberos credential delegation"Stephen Frost2023-04-13
| | | | | | | | | | | | | | | | | | This reverts commit 3d03b24c3 (Revert Add support for Kerberos credential delegation) which was committed on the grounds of concern about portability, but on further review and discussion, it's clear that we are better off explicitly requiring MIT Kerberos as that appears to be the only GSSAPI library currently that's under proper maintenance and ongoing development. The API used for storing credentials was added to MIT Kerberos over a decade ago while for the other libraries which appear to be mainly based on Heimdal, which exists explicitly to be a re-implementation of MIT Kerberos, the API never made it to a released version (even though it was added to the Heimdal git repo over 5 years ago..). This post-feature-freeze change was approved by the RMT. Discussion: https://postgr.es/m/ZDDO6jaESKaBgej0%40tamriel.snowman.net
* doc: Make HTML ids discoverablePeter Eisentraut2023-04-13
| | | | | | | | | | | | | | | In the HTML output, this decorates section headers and variable list terms with a marker ("#") that is a link to the same section/term. That way, links inside a page can be discovered for easier sharing. The marker only appears when hovering. This now requires that all elements that are candidates for such a link have an id attribute. Otherwise, an error will be generated. All previously missing ids have been added prior to this patch. Author: Brar Piening <brar@gmx.de> Reviewed-by: Karl O. Pinc <kop@karlpinc.com> Discussion: https://www.postgresql.org/message-id/flat/CAB8KJ=jpuQU9QJe4+RgWENrK5g9jhoysMw2nvTN_esoOU0=a_w@mail.gmail.com
* Add missing XML ID attributePeter Eisentraut2023-04-13
| | | | Discussion: https://www.postgresql.org/message-id/dc813a6f-60d9-991f-eecd-675a0921de11@gmx.de
* Skip the 004_io_direct.pl test if a pre-flight check fails.Thomas Munro2023-04-13
| | | | | | | | | | | | | | | | | The test previously had a list of OSes that direct I/O was expected to work on. That worked well enough for the systems in our build farm, but didn't survive contact with the Debian build bots running on tmpfs via overlayfs. tmpfs does not support O_DIRECT, but we don't want to exclude Linux generally. The new approach is to try to create an empty file with O_DIRECT from Perl first. If that fails, we'll skip the test and report what the error was. Reported-by: Christoph Berg <myon@debian.org> Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/ZDYd4A78cT2ULxZZ%40msg.df7cb.de
* Remove overzealous assertion from PHJ.Thomas Munro2023-04-13
| | | | | | | | | | | | | | We can't assert that we're the only process attached to a barrier after BarrierArriveAndDetachExceptLast(). Although that'll be true almost always, a late-starting parallel worker can attach very briefly (that is, immediately detach after checking the phase) right at that moment. BarrierArriveAndDetachExceptLast() already contains an assertion like that, but it holds a spinlock preventing the race. This thinko caused a one-off failure on build farm animal chimaera. Diagnosed-by: Melanie Plageman <melanieplageman@gmail.com> Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3590249.1680971629@sss.pgh.pa.us
* Revert "Adjust contrib/sepgsql regression test expected outputs."Alvaro Herrera2023-04-12
| | | | | | | This reverts commit 76c111a7f166; should have been included in 9ce04b50e120. Noted by Joe Conway
* Improve error messages introduced in be87200efd9 and 0fdab27ad68Andres Freund2023-04-12
| | | | | | Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20230411.120301.93333867350615278.horikyota.ntt@gmail.com Discussion: https://postgr.es/m/20230412174244.6njadz4uoiez3l74@awork3.anarazel.de
* Revert "Catalog NOT NULL constraints" and falloutAlvaro Herrera2023-04-12
| | | | | | | | | | | This reverts commit e056c557aef4 and minor later fixes thereof. There's a few problems in this new feature -- most notably regarding pg_upgrade behavior, but others as well. This new feature is not in any way critical on its own, so instead of scrambling to fix it we revert it and try again in early 17 with these issues in mind. Discussion: https://postgr.es/m/3801207.1681057430@sss.pgh.pa.us
* basebackup_to_shell: Check for a NULL return from OpenPipeStream.Robert Haas2023-04-12
| | | | | | Per complaint from Peter Eisentraut. Discussion: http://postgr.es/m/4f1707cc-2432-da35-64a2-5c2a8d92a388@enterprisedb.com
* Document BaseBackupSync and BaseBackupWrite wait events.Robert Haas2023-04-12
| | | | | | | | | Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc should have done this, but I overlooked it. Per complaint from Thomas Munro. Discussion: http://postgr.es/m/CA+hUKGJixAHc860Ej9Qzd_z96Z6aoajAgJ18bYfV3Lfn6t9=+Q@mail.gmail.com
* Fix parallel-safety marking when moving initplans to another node.Tom Lane2023-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our policy since commit ab77a5a45 has been that a plan node having any initplans is automatically not parallel-safe. (This could be relaxed, but not today.) clean_up_removed_plan_level neglected this, and could attach initplans to a parallel-safe child plan node without clearing the plan's parallel-safe flag. That could lead to "subplan was not initialized" errors at runtime, in case an initplan referenced another one and only the referencing one got transmitted to parallel workers. The fix in clean_up_removed_plan_level is trivial enough. materialize_finished_plan also moves initplans from one node to another, but it's okay because it already copies the source node's parallel_safe flag. The other place that does this kind of thing is standard_planner's hack to inject a top-level Gather when debug_parallel_query is active. But that's actually dead code given that we're correctly enforcing the "initplans aren't parallel safe" rule, so just replace it with an Assert that there are no initplans. Also improve some related comments. Normally we'd add a regression test case for this sort of bug. The mistake itself is already reached by existing tests, but there is accidentally no visible problem. The only known test case that creates an actual failure seems too indirect and fragile to justify keeping it as a regression test (not least because it fails to fail in v11, though the bug is clearly present there too). Per report from Justin Pryzby. Back-patch to all supported branches. Discussion: https://postgr.es/m/ZDVt6MaNWkRDO1LQ@telsasoft.com
* doc: Reword unexplained abbreviationDaniel Gustafsson2023-04-12
| | | | | | | | | | | | | The previous wording used MVF to indicate the Most Common Values' Frequencies, but the abbreviation was never explained or defined. Reword to mcv_freqs to make the use clearer. Also add MCF and MCV as acronyms as they were using <acronym> markup but were missing from the acronyms page. Reported-by: Eric Mutta <eric.mutta@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/166112292492.654.5377188452604176150@wrigleys.postgresql.org
* Fix incorrect format placeholdersPeter Eisentraut2023-04-12
|
* Update config.guess and config.subPeter Eisentraut2023-04-12
|
* doc: Fix some typos and grammarMichael Paquier2023-04-12
| | | | | | | | This is a first batch of the fixes, for the most obvious fixes. A little bit more is under discussion. Author: Thom Brown, Justin Pryzby Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com
* Fix detection of unseekable files for fseek() and ftello() with MSVCMichael Paquier2023-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling fseek() or ftello() on a handle to a non-seeking device such as a pipe or a communications device is not supported. Unfortunately, MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not return an error when given a pipe as handle. Some of the logic of pg_dump and restore relies on these routines to check if a handle is seekable, causing failures when passing the contents of pg_dump to pg_restore through a pipe, for example. This commit introduces wrappers for fseeko() and ftello() on MSVC so as any callers are able to properly detect the cases of non-seekable handles. This relies mainly on GetFileType(), sharing a bit of code with the MSVC port for fstat(). The code in charge of getting a file type is refactored into a new file called win32common.c, shared by win32stat.c and the new win32fseek.c. It includes the MSVC ports for fseeko() and ftello(). Like 765f5df, this is backpatched down to 14, where the fstat() implementation for MSVC is able to understand about files larger than 4GB in size. Using a TAP test for that is proving to be tricky as IPC::Run handles the pipes by itself, still I have been able to check the fix manually. Reported-by: Daniel Watzinger Author: Juan José Santamaría Flecha, Michael Paquier Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com Backpatch-through: 14
* Refine the guidelines for rmgrdesc authors.Peter Geoghegan2023-04-11
| | | | | | | | | | | | | | | | Clarify the goals of the recently added guidelines for rmgrdesc authors: to avoid gratuitous inconsistencies across resource managers, and to make it reasonably easy to write a reusable custom parser. Beyond that, the guidelines leave rmgrdesc authors with a significant amount of leeway. This even includes the leeway to invent custom conventions (in cases where it's warranted). Follow-up to commit 7d8219a4. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/CAH2-WzkbYuvwYKm-Y-72QEh6SPMQcAo9uONv+mR3bMGcu9E_Cg@mail.gmail.com
* Fix Heap rmgr's desc output for infobits arrays.Peter Geoghegan2023-04-11
| | | | | | | | | | | | | | | | | | | Make heap desc routines that output status bit as arrays of constants avoid outputting array literals that contain superfluous punctuation characters that complicate parsing the output. Also make sure that no heap desc routine repeats the same key name (at the same nesting level), for the same reason. Arguably, these were both oversights in commit 7d8219a4. In passing, make the desc output code (which covers Heap's DELETE, UPDATE, HOT_UPDATE, LOCK, and LOCK_UPDATED record types) consistent in terms of the output order of each field. This order also matches WAL record struct order. Heap's DELETE desc output now shows the record's xmax field for the first time (just like UPDATE/HOT_UPDATE records). Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/CAH2-Wz=pNYtxiJ2Jx5Lj=fKo1OEZ4GE0p_kct+ugAUTqBwU46g@mail.gmail.com
* Fix xl_heap_lock WAL record field's data type.Peter Geoghegan2023-04-11
| | | | | | | | | | | | | | Make xl_heap_lock's infobits_set field of type uint8, not int8. Using int8 isn't appropriate given that the field just holds status bits. This fixes an oversight in commit 0ac5ad5134. In passing rename the nearby TransactionId field to "xmax" to make things consistency with related records, such as xl_heap_lock_updated. Deliberately avoid a bump in XLOG_PAGE_MAGIC. No backpatch, either. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkCd3kOS8b7Rfxw7Mh1_6jvX=Nzo-CWR1VBTiOtVZkWHA@mail.gmail.com
* 035_standby_logical_decoding: Add missing waits for replicationAndres Freund2023-04-11
| | | | | | | | | | At least one slow buildfarm system (hoverfly) showed that the database creation was not replicated before we try to create logical replication slots on the standby, in that database. Reported-by: Noah Misch <noah@leadboat.com> Author: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/20230411053657.GA1177147@rfd.leadboat.com
* Document new pg_subscription columns.Robert Haas2023-04-11
| | | | | | | | | | Commit 482675987bcdffb390ae735cfd5f34b485ae97c6 and commit c3afe8cf5a1e465bd71e48e4bc717f5bfdc7a7d6 forgot to take care of this. Noriyoshi Shinoda Discussion: http://postgr.es/m/DM4PR84MB17345D8760165F14A199B81CEE9A9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* Fix uninitialized variable in transformTableLikeClause()David Rowley2023-04-11
| | | | | | | | | process_notnull_constraints should be set to false until we discover a NOT NULL column. Discovered while running Valgrind. Discussion: https://postgr.es/m/CAApHDvoMyiZVi1KW5WVdqMRzWsWkD3F7n6QD+BbAO6WTeAWsUQ@mail.gmail.com
* Improve ereports for VACUUM's BUFFER_USAGE_LIMIT optionDavid Rowley2023-04-11
| | | | | | | | | | | | | | There's no need to check if opt->arg is NULL since defGetString() already does that and raises an ERROR if it is. Let's just remove that check. Also, combine the two remaining ERRORs into a single check. It seems better to give an indication about what sort of values we're looking for rather than just to state that the value given isn't valid. Make BUFFER_USAGE_LIMIT uppercase in this ERROR message too. It's already upper case in one other error message, so make that consistent. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230411.102335.1643720544536884844.horikyota.ntt@gmail.com