aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Doc: fix outdated protocol version.Tatsuo Ishii2025-07-11
| | | | | | | | | | | | | In the description of StartupMessage, the protocol version was left 3.0. Instead of just updating it, this commit removes the hard coded protocol version and shows the numbers as an example. This makes that the part of the doc does not need to be updated when the version is changed in the future. Author: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Tatsuo Ishii <ishii@postgresql.org> Reviewed-by: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://postgr.es/m/20250626.155608.568829483879866256.ishii%40postgresql.org
* doc: Clarify meaning of "idle" in idle_replication_slot_timeout.Fujii Masao2025-07-11
| | | | | | | | | | | | | | | | | | | | This commit updates the documentation to clarify that "idle" in idle_replication_slot_timeout means the replication slot is inactive, that is, not currently used by any replication connection. Without this clarification, "idle" could be misinterpreted to mean that the slot is not advancing or that no data is being streamed, even if a connection exists. Back-patch to v18 where idle_replication_slot_timeout was added. Author: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Gunnar Morling <gunnar.morling@googlemail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com Backpatch-through: 18
* Change unit of idle_replication_slot_timeout to seconds.Fujii Masao2025-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, the idle_replication_slot_timeout parameter used minutes as its unit, based on the assumption that values would typically exceed one minute in production environments. However, this caused unexpected behavior: specifying a value below 30 seconds would round down to 0, effectively disabling the timeout. This could be surprising to users. To allow finer-grained control and avoid such confusion, this commit changes the unit of idle_replication_slot_timeout to seconds. Larger values can still be specified easily using standard time suffixes, for example, '24h' for 24 hours. Back-patch to v18 where idle_replication_slot_timeout was added. Reported-by: Gunnar Morling <gunnar.morling@googlemail.com> Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com Backpatch-through: 18
* Fix sslkeylogfile error handling loggingDaniel Gustafsson2025-07-10
| | | | | | | | | | | | | | | | | | When sslkeylogfile has been set but the file fails to open in an otherwise successful connection, the log entry added to the conn object is never printed. Instead print the error on stderr for increased visibility. This is a debugging tool so using stderr for logging is appropriate. Also while there, remove the umask call in the callback as it's not useful. Issues noted by Peter Eisentraut in post-commit review, backpatch down to 18 when support for sslkeylogfile was added Author: Daniel Gustafsson <daniel@yesql.se> Reported-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/70450bee-cfaa-48ce-8980-fc7efcfebb03@eisentraut.org Backpatch-through: 18
* pg_dump: Fix object-type sort priority for large objects.Nathan Bossart2025-07-10
| | | | | | | | | | | | | | | | Commit a45c78e328 moved large object metadata from SECTION_PRE_DATA to SECTION_DATA but neglected to move PRIO_LARGE_OBJECT in dbObjectTypePriorities accordingly. While this hasn't produced any known live bugs, it causes problems for a proposed patch that optimizes upgrades with many large objects. Fixing the priority might also make the topological sort step marginally faster by reducing the number of ordering violations that have to be fixed. Reviewed-by: Nitin Motiani <nitinmotiani@google.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/aBkQLSkx1zUJ-LwJ%40nathan Discussion: https://postgr.es/m/aG_5DBCjdDX6KAoD%40nathan Backpatch-through: 17
* btree_gist: Merge the last two versions into version 1.8Michael Paquier2025-07-10
| | | | | | | | | | | | | | | | During the development cycle of v18, btree_gist has been bumped once to 1.8 for the addition of translate_cmptype support functions (originally 7406ab623fee, renamed in 32edf732e8dc). 1.9 has added sortsupport functions (e4309f73f698). There is no need for two version bumps in a module for a single major release of PostgreSQL. This commit unifies both upgrades to a single SQL script, downgrading btree_gist to 1.8. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/13c61807-f702-4afe-9a8d-795e2fd40923@illuminatedcomputing.com Backpatch-through: 18
* injection_points: Add injection_points_list()Michael Paquier2025-07-10
| | | | | | | | | | | | | | | This function can be used to retrieve the information about all the injection points attached to a cluster, providing coverage for InjectionPointList() introduced in 7b2eb72b1b8c. The original proposal turned around a system function, but that would not be backpatchable to stable branches. It was also a bit weird to have a system function that fails depending on if the build allows injection points or not. Reviewed-by: Aleksander Alekseev <aleksander@timescale.com> Reviewed-by: Rahila Syed <rahilasyed90@gmail.com> Discussion: https://postgr.es/m/Z_xYkA21KyLEHvWR@paquier.xyz
* Use pg_assume() to avoid compiler warning below exec_set_found()Andres Freund2025-07-09
| | | | | | | | | | The warning, visible when building with -O3 and a recent-ish gcc, is due to gcc not realizing that found is a byvalue type and therefore will never be interpreted as a varlena type. Discussion: https://postgr.es/m/3prdb6hkep3duglhsujrn52bkvnlkvhc54fzvph2emrsm4vodl@77yy6j4hkemb Discussion: https://postgr.es/m/20230316172818.x6375uvheom3ibt2%40awork3.anarazel.de Discussion: https://postgr.es/m/20240207203138.sknifhlppdtgtxnk%40awork3.anarazel.de
* Add pg_assume(expr) macroAndres Freund2025-07-09
| | | | | | | | | | | | This macro can be used to avoid compiler warnings, particularly when using -O3 and not using assertions, and to get the compiler to generate better code. A subsequent commit introduces a first user. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3prdb6hkep3duglhsujrn52bkvnlkvhc54fzvph2emrsm4vodl@77yy6j4hkemb Discussion: https://postgr.es/m/20230316172818.x6375uvheom3ibt2%40awork3.anarazel.de Discussion: https://postgr.es/m/20240207203138.sknifhlppdtgtxnk%40awork3.anarazel.de
* Link libpq with libdl if the platform needs that.Tom Lane2025-07-09
| | | | | | | | | | | | Since b0635bfda, libpq uses dlopen() and related functions. On some platforms these are not supplied by libc, but by a separate library libdl, in which case we need to make sure that that dependency is known to the linker. Meson seems to take care of that automatically, but the Makefile didn't cater for it. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/1328170.1752082586@sss.pgh.pa.us Backpatch-through: 18
* Change wchar2char() and char2wchar() to accept a locale_t.Jeff Davis2025-07-09
| | | | | | | These are libc-specific functions, so should require a locale_t rather than a pg_locale_t (which could use another provider). Discussion: https://postgr.es/m/a8666c391dfcabe79868d95f7160eac533ace718.camel%40j-davis.com
* Minor tweaks for pg_test_timing.Tom Lane2025-07-09
| | | | | | | | | | | | | | | | | | | Increase the size of the "direct" histogram to 10K elements, so that we can precisely track loop times up to 10 microseconds. (Going further than that seems pretty uninteresting, even for very old and slow machines.) Relabel "Per loop time" as "Average loop time" for clarity. Pre-zero the histogram arrays to make sure that they are loaded into processor cache and any copy-on-write overhead has happened before we enter the timing loop. Also use unlikely() to keep the compiler from thinking that the clock-went-backwards case is part of the hot loop. Neither of these hacks made a lot of difference on my own machine, but they seem like they might help on some platforms. Discussion: https://postgr.es/m/be0339cc-1ae1-4892-9445-8e6d8995a44d@eisentraut.org
* Introduce pg_dsm_registry_allocations view.Nathan Bossart2025-07-09
| | | | | | | | | | | | | | | This commit adds a new system view that provides information about entries in the dynamic shared memory (DSM) registry. Specifically, it returns the name, type, and size of each entry. Note that since we cannot discover the size of dynamic shared memory areas (DSAs) and hash tables backed by DSAs (dshashes) without first attaching to them, the size column is left as NULL for those. Bumps catversion. Author: Florents Tselai <florents.tselai@gmail.com> Reviewed-by: Sungwoo Chang <swchangdev@gmail.com> Discussion: https://postgr.es/m/4D445D3E-81C5-4135-95BB-D414204A0AB4%40gmail.com
* Fix tab-completion for COPY and \copy options.Masahiko Sawada2025-07-09
| | | | | | | | | | | | | | | | | | | Commit c273d9d8ce4 reworked tab-completion of COPY and \copy in psql and added support for completing options within WITH clauses. However, the same COPY options were suggested for both COPY TO and COPY FROM commands, even though some options are only valid for one or the other. This commit separates the COPY options for COPY FROM and COPY TO commands to provide more accurate auto-completion suggestions. Back-patch to v14 where tab-completion for COPY and \copy options within WITH clauses was first supported. Author: Atsushi Torikoshi <torikoshia@oss.nttdata.com> Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp> Discussion: https://postgr.es/m/079e7a2c801f252ae8d522b772790ed7@oss.nttdata.com Backpatch-through: 14
* psql: Improve psql tab completion for GRANT/REVOKE on large objects.Fujii Masao2025-07-09
| | | | | | | | | | | | This commit enhances psql's tab completion to support TO/FROM after "GRANT/REVOKE ... ON LARGE OBJECT ...". Additionally, since "ALTER DEFAULT PRIVILEGES" now supports large objects, tab completion is also updated for "GRANT/REVOKE ... ON LARGE OBJECTS" with TO/FROM. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp> Discussion: https://postgr.es/m/ade0ab29-777f-47f6-9d0d-1af67728a86e@oss.nttdata.com
* Hide ICU C++ APIs from pg_locale.hJohn Naylor2025-07-09
| | | | | | | | | | | | | | | | | | | | | | The cpluspluscheck script wraps our headers in `extern "C"`. This disables name mangling, which is necessary for the C++ templates in system ICU headers. cpluspluscheck thus fails when the build is configured with ICU (the default). CI worked around this by disabling ICU, but let's make it work so others can run the script. We can specify we only want the C APIs by defining U_SHOW_CPLUSPLUS_API to be 0 in pg_locale.h. Extensions that want the C++ APIs can include ICU headers separately before including PostgreSQL headers. ICU documentation: https://github.com/unicode-org/icu/blob/main/docs/processes/release/tasks/healthy-code.md#test-icu4c-headers Suggested-by: Andres Freund <andres@anarazel.de> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220323002024.f2g6tivduzrktgfa%40alap3.anarazel.de Discussion: https://postgr.es/m/CANWCAZbgiaz1_0-F4SD%2B%3D-e9onwAnQdBGJbhg94EqUu4Gb7WyA%40mail.gmail.com
* libpq: Add TAP test for nested service fileMichael Paquier2025-07-09
| | | | | | | | | | | | This test corresponds to the case of a "service" defined in a service file, that libpq is not able to support in parseServiceFile(). This has come up during the review of a patch to add more features in this area, useful on its own. Piece extracted from a larger patch by the same author. Author: Ryo Kanbayashi <kanbayashi.dev@gmail.com> Discussion: https://postgr.es/m/Zz2AE7NKKLIZTtEh@paquier.xyz
* Doc: Improve logical replication failover documentation.Amit Kapila2025-07-09
| | | | | | | | | | | | Clarified that the failover steps apply to a specific PostgreSQL subscriber and added guidance for verifying replication slot synchronization during planned failover. Additionally, corrected the standby query to avoid false positives by checking invalidation_reason IS NULL instead of conflicting. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Author: Shveta Malik <shveta.malik@gmail.com> Backpatch-through: 17, where it was introduced Discussion: https://www.postgresql.org/message-id/CAExHW5uiZ-fF159=jwBwPMbjZeZDtmcTbN+hd4mrURLCg2uzJg@mail.gmail.com
* libpq: Remove PQservice()Michael Paquier2025-07-09
| | | | | | | | | | | | | | | This routine has been introduced as a shortcut to be able to retrieve a service name from an active connection, for psql. Per discussion, and as it is only used by psql, let's remove it to not clutter the libpq API more than necessary. The logic in psql is replaced by lookups of PQconninfoOption for the active connection, instead, updated each time the variables are synced by psql, the prompt shortcut relying on the variable synced. Reported-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/20250706161319.c1.nmisch@google.com Backpatch-through: 18
* Fix up misuse of "volatile" in contrib/xml2.Tom Lane2025-07-08
| | | | | | | | | | | | | | | | | | | | | | | | What we want in these places is "xmlChar *volatile ptr", not "volatile xmlChar *ptr". The former means that the pointer variable itself needs to be treated as volatile, while the latter says that what it points to is volatile. Since the point here is to ensure that the pointer variables don't go crazy after a longjmp, it's the former semantics that we need. The misplacement of "volatile" also led to needing to cast away volatile in some places. Also fix a number of places where variables that are assigned to within a PG_TRY and then used after it were not initialized or not marked as volatile. (A few buildfarm members were issuing "may be used uninitialized" warnings about some of these variables, which is what drew my attention to this area.) In most cases these variables were being set as the last step within the PG_TRY block, which might mean that we could get away without the "volatile" marking. But doing that seems unsafe and is definitely not per our coding conventions. These problems seem to have come in with 732061150, so no need for back-patch.
* Fix low-probability memory leak in XMLSERIALIZE(... INDENT).Tom Lane2025-07-08
| | | | | | | | | | | | | xmltotext_with_options() did not consider the possibility that pg_xml_init() could fail --- most likely due to OOM. If that happened, the already-parsed xmlDoc structure would be leaked. Oversight in commit 483bdb2af. Bug: #18981 Author: Dmitry Kovalenko <d.kovalenko@postgrespro.ru> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18981-9bc3c80f107ae925@postgresql.org Backpatch-through: 16
* Fix a couple more places in docs for pg_lsn changeÁlvaro Herrera2025-07-08
| | | | | | | Also, revert Unicode linestyle to ASCII. Reported-by: Japin Li <japinli@hotmail.com> Discussion: https://postgr.es/m/ME0P300MB04453A39931F95805C4205A8B64FA@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM
* Change pg_test_timing to measure in nanoseconds not microseconds.Tom Lane2025-07-08
| | | | | | | | | | | | | | | | | | | | | Most of our platforms have better-than-microsecond timing resolution, so the original definition of this program is getting less and less useful. Make it report nanoseconds not microseconds. Also, add a second output table that reports the exact observed timing durations, up to a limit of 1024 ns; and be sure to report the largest observed duration. The documentation for this program included a lot of system-specific details that now seem largely obsolete. Move all that text to the PG wiki, where perhaps it will be easier to maintain and update. Also, improve the TAP test so that it actually runs a short standard run, allowing most of the code to be exercised; its coverage before was abysmal. Author: Hannu Krosing <hannuk@google.com> Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/be0339cc-1ae1-4892-9445-8e6d8995a44d@eisentraut.org
* pg_walsummary: Improve stability of test checking statisticsMichael Paquier2025-07-08
| | | | | | | | | | | | | | | | Per buildfarm member culicidae, the query checking for stats reported by the WAL summarizer related to WAL reads is proving to be unstable. Instead of a one-time query, this commit replaces the logic with a polling query checking for the WAL read stats, making the test more reliable on machines that could be slow with the stats reports. This test has been introduced in f4694e0f35b2, so backpatch down to v18. Reported-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/f35ba3db-fca7-4693-bc35-6db64488e4b1@gmail.com Backpatch-through: 18
* aio: Combine io_uring memory mappings, if supportedAndres Freund2025-07-07
| | | | | | | | | | | | | | | | | | By default io_uring creates a shared memory mapping for each io_uring instance, leading to a large number of memory mappings. Unfortunately a large number of memory mappings slows things down, backend exit is particularly affected. To address that, newer kernels (6.5) support using user-provided memory for the memory. By putting the relevant memory into shared memory we don't need any additional mappings. On a system with a new enough kernel and liburing, there is no discernible overhead when doing a pgbench -S -C anymore. Reported-by: MARK CALLAGHAN <mdcallag@gmail.com> Reviewed-by: "Burd, Greg" <greg@burd.me> Reviewed-by: Jim Nasby <jnasby@upgrade.com> Discussion: https://postgr.es/m/CAFbpF8OA44_UG+RYJcWH9WjF7E3GA6gka3gvH6nsrSnEe9H0NA@mail.gmail.com Backpatch-through: 18
* Consider explicit incremental sort for Append and MergeAppendRichard Guo2025-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | For an ordered Append or MergeAppend, we need to inject an explicit sort into any subpath that is not already well enough ordered. Currently, only explicit full sorts are considered; incremental sorts are not yet taken into account. In this patch, for subpaths of an ordered Append or MergeAppend, we choose to use explicit incremental sort if it is enabled and there are presorted keys. The rationale is based on the assumption that incremental sort is always faster than full sort when there are presorted keys, a premise that has been applied in various parts of the code. In addition, the current cost model tends to favor incremental sort as being cheaper than full sort in the presence of presorted keys, making it reasonable not to consider full sort in such cases. No backpatch as this could result in plan changes. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CAMbWs4_V7a2enTR+T3pOY_YZ-FU8ZsFYym2swOz4jNMqmSgyuw@mail.gmail.com
* oauth: Fix kqueue detection on OpenBSDJacob Champion2025-07-07
| | | | | | | | | | | | | | | | | | | | | | In b0635bfda, I added an early header check to the Meson OAuth support, which was intended to duplicate the later checks for HAVE_SYS_[EVENT|EPOLL]_H. However, I implemented the new test via check_header() -- which tries to compile -- rather than has_header(), which just looks for the file's existence. The distinction matters on OpenBSD, where <sys/event.h> can't be compiled without including prerequisite headers, so -Dlibcurl=enabled failed on that platform. Switch to has_header() to fix this. Note that reviewers expressed concern about the difference between our Autoconf feature tests (which compile headers) and our Meson feature tests (which do not). I'm not opposed to aligning the two, but I want to avoid making bigger changes as part of this fix. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/flat/CAOYmi+kdR218ke2zu74oTJvzYJcqV1MN5=mGAPqZQuc79HMSVA@mail.gmail.com Backpatch-through: 18
* Adapt pg_upgrade test to pg_lsn output format differenceÁlvaro Herrera2025-07-07
| | | | | | | | | | | Commit 2633dae2e487 added some zero padding to various LSNs output routines so that the low word is always 8 hex digits long, for easy human consumption. This included the pg_lsn datatype, which breaks the pg_upgrade test when it compares the pg_dump output of an older version. Silence this problem by setting the pg_lsn columns to NULL before the upgrade. Discussion: https://postgr.es/m/202507071504.xm2r26u7lmzr@alvherre.pgsql
* Restore the ability to run pl/pgsql expression queries in parallel.Tom Lane2025-07-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pl/pgsql's notion of an "expression" is very broad, encompassing any SQL SELECT query that returns a single column and no more than one row. So there are cases, for example evaluation of an aggregate function, where the query involves significant work and it'd be useful to run it with parallel workers. This used to be possible, but commits 3eea7a0c9 et al unintentionally disabled it. The simplest fix is to make exec_eval_expr() pass maxtuples = 0 rather than 2 to exec_run_select(). This avoids the new rule that we will never use parallelism when a nonzero "count" limit is passed to ExecutorRun(). (Note that the pre-3eea7a0c9 behavior was indeed unsafe, so reverting that rule is not in the cards.) The reason for passing 2 before was that exec_eval_expr() will throw an error if it gets more than one returned row, so we figured that as soon as we have two rows we know that will happen and we might as well stop running the query. That choice was cost-free when it was made; but disabling parallelism is far from cost-free, so now passing 2 amounts to optimizing a failure case at the expense of useful cases. An expression query that can return more than one row is certainly broken. People might now need to wait a bit longer to discover such breakage; but hopefully few will use enormously expensive cases as their first test of new pl/pgsql logic. Author: Dipesh Dhameliya <dipeshdhameliya125@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CABgZEgdfbnq9t6xXJnmXbChNTcWFjeM_6nuig41tm327gYi2ig@mail.gmail.com Backpatch-through: 13
* Refactor some repetitive SLRU codeÁlvaro Herrera2025-07-07
| | | | | | | | | | | | | | | | | Functions to bootstrap and zero pages in various SLRU callers were fairly duplicative. We can slash almost two hundred lines with a couple of simple helpers: - SimpleLruZeroAndWritePage: Does the equivalent of SimpleLruZeroPage followed by flushing the page to disk - XLogSimpleInsertInt64: Does a XLogBeginInsert followed by XLogInsert of a trivial record whose data is just an int64. Author: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com> Reviewed by: Álvaro Herrera <alvherre@kurilemu.de> Reviewed by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed by: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://www.postgresql.org/message-id/flat/97820ce8-a1cd-407f-a02b-47368fadb14b%40tantorlabs.com
* Standardize LSN formatting by zero paddingÁlvaro Herrera2025-07-07
| | | | | | | | | | | | | | | | This commit standardizes the output format for LSNs to ensure consistent representation across various tools and messages. Previously, LSNs were inconsistently printed as `%X/%X` in some contexts, while others used zero-padding. This often led to confusion when comparing. To address this, the LSN format is now uniformly set to `%X/%08X`, ensuring the lower 32-bit part is always zero-padded to eight hexadecimal digits. Author: Japin Li <japinli@hotmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://postgr.es/m/ME0P300MB0445CA53CA0E4B8C1879AF84B641A@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM
* Integrate FullTransactionIds deeper into two-phase codeMichael Paquier2025-07-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This refactoring is a follow-up of the work done in 5a1dfde8334b, that has switched 2PC file names to use FullTransactionIds when written on disk. This will help with the integration of a follow-up solution related to the handling of two-phase files during recovery, to address older defects while reading these from disk after a crash. This change is useful in itself as it reduces the need to build the file names from epoch numbers and TransactionIds, because we can use directly FullTransactionIds from which the 2PC file names are guessed. So this avoids a lot of back-and-forth between the FullTransactionIds retrieved from the file names and how these are passed around in the internal 2PC logic. Note that the core of the change is the use of a FullTransactionId instead of a TransactionId in GlobalTransactionData, that tracks 2PC file information in shared memory. The change in TwoPhaseCallback makes this commit unfit for stable branches. Noah has contributed a good chunk of this patch. I have spent some time on it as well while working on the issues with two-phase state files and recovery. Author: Noah Misch <noah@leadboat.com> Co-Authored-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/Z5sd5O9JO7NYNK-C@paquier.xyz Discussion: https://postgr.es/m/20250116205254.65.nmisch@google.com
* Fix incompatibility with libxml2 >= 2.14Michael Paquier2025-07-07
| | | | | | | | | | | | | | | | | | | | libxml2 has deprecated the members of xmlBuffer, and it is recommended to access them with dedicated routines. We have only one case in the tree where this shows an impact: xml2/xpath.c where "content" was getting directly accessed. The rest of the code looked fine, checking the PostgreSQL code with libxml2 close to the top of its "2.14" branch. xmlBufferContent() exists since year 2000 based on a check of the upstream libxml2 tree, so let's switch to it. Like 400928b83bd2, backpatch all the way down as this can have an impact on all the branches already released once newer versions of libxml2 get more popular. Reported-by: Walid Ibrahim <walidib@amazon.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/aGdSdcR4QTjEHX6s@paquier.xyz Backpatch-through: 13
* postgres_fdw: Add Assert to estimate_path_cost_size().Etsuro Fujita2025-07-06
| | | | | | | | | | | | | | When estimating the cost/size of a pre-sorted path for a given upper relation using local stats, this function dereferences the passed-in PgFdwPathExtraData pointer without checking that it is not NULL. But that is not a bug as the pointer is guaranteed to be non-NULL in that case; to avoid confusion, add an Assert to ensure that it is not NULL before dereferencing it. Reported-by: Ranier Vilela <ranier.vf@gmail.com> Author: Etsuro Fujita <etsuro.fujita@gmail.com> Reviewed-by: Ranier Vilela <ranier.vf@gmail.com> Discussion: https://postgr.es/m/CAEudQArgiALbV1akQpeZOgim7XP05n%3DbDP1%3DTcOYLA43nRX_vA%40mail.gmail.com
* Fix new pg_upgrade query not to rely on regnamespaceÁlvaro Herrera2025-07-04
| | | | | | | That was invented in 9.5, and pg_upgrade claims to support back to 9.0. But we don't need that with a simple query change, tested by Tom Lane. Discussion: https://postgr.es/m/202507041645.afjl5rssvrgu@alvherre.pgsql
* pg_upgrade: Add missing newline in error messageÁlvaro Herrera2025-07-04
| | | | Minor oversight in 347758b12063
* pg_upgrade: check for inconsistencies in not-null constraints w/inheritanceÁlvaro Herrera2025-07-04
| | | | | | | | | | | | | | | | | | | | | With tables defined like this, CREATE TABLE ip (id int PRIMARY KEY); CREATE TABLE ic (id int) INHERITS (ip); ALTER TABLE ic ALTER id DROP NOT NULL; pg_upgrade fails during the schema restore phase due to this error: ERROR: column "id" in child table must be marked NOT NULL This can only be fixed by marking the child column as NOT NULL before the upgrade, which could take an arbitrary amount of time (because ic's data must be scanned). Have pg_upgrade's check mode warn if that condition is found, so that users know what to adjust before running the upgrade for real. Author: Ali Akbar <the.apaan@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Backpatch-through: 13 Discussion: https://postgr.es/m/CACQjQLoMsE+1pyLe98pi0KvPG2jQQ94LWJ+PTiLgVRK4B=i_jg@mail.gmail.com
* amcheck: Remove unused IndexCheckableCallback typedef.Fujii Masao2025-07-04
| | | | | | | | | | Commit d70b17636dd introduced the IndexCheckableCallback typedef for a callback function, but it was never used. This commit removes the unused typedef to clean up dead code. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/e1ea4e14-3b21-4e01-a5f2-0686883265df@oss.nttdata.com
* Disable commit timestamps during bootstrapMichael Paquier2025-07-04
| | | | | | | | | | | | | | | | | | | | | | | Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda <kuroda.hayato@fujitsu.com> Author: Andy Fan <zhihuifan1213@163.com> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/OSCPR01MB14966FF9E4C4145F37B937E52F5102@OSCPR01MB14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy.fsf@163.com Backpatch-through: 13
* Speed up truncation of temporary relations.Fujii Masao2025-07-04
| | | | | | | | | | | | | | | | | | | | Previously, truncating a temporary relation required scanning the entire local buffer pool once per relation fork to invalidate buffers. This could be slow, especially with a large local buffers, as the scan was repeated multiple times. A similar issue with regular tables (shared buffers) was addressed in commit 6d05086c0a7 by scanning the buffer pool only once for all forks. This commit applies the same optimization to temporary relations, improving truncation performance. Author: Daniil Davydov <3danissimo@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com> Reviewed-by: Maxim Orlov <orlovmg@gmail.com> Discussion: https://postgr.es/m/CAJDiXggNqsJOH7C5co4jA8nDk8vw-=sokyh5s1_TENWnC6Ofcg@mail.gmail.com
* Simplify COALESCE() with one surviving argument.Tom Lane2025-07-03
| | | | | | | | | | | | | | | | | | | | | If, after removal of useless null-constant arguments, a CoalesceExpr has exactly one remaining argument, we can just take that argument as the result, without bothering to wrap a new CoalesceExpr around it. This isn't likely to produce any great improvement in runtime per se, but it can lead to better plans since the planner no longer has to treat the expression as non-strict. However, there were a few regression test cases that intentionally wrote COALESCE(x) as a shorthand way of creating a non-strict subexpression. To avoid ruining the intent of those tests, write COALESCE(x,x) instead. (If anyone ever proposes de-duplicating COALESCE arguments, we'll need another iteration of this arms race. But it seems pretty unlikely that such an optimization would be worthwhile.) Author: Maksim Milyutin <maksim.milyutin@tantorlabs.ru> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/8e8573c3-1411-448d-877e-53258b7b2be0@tantorlabs.ru
* Add more cross-type comparisons to contrib/btree_gin.Tom Lane2025-07-03
| | | | | | | | | | | Using the just-added infrastructure, extend btree_gin to support cross-type operators in its other opclasses. All of the cross-type comparison operators supported by the core btree opclasses for these datatypes are now available for btree_gin indexes as well. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> Discussion: https://postgr.es/m/262624.1738460652@sss.pgh.pa.us
* Add cross-type comparisons to contrib/btree_gin.Tom Lane2025-07-03
| | | | | | | | | | | | | Extend the infrastructure in btree_gin.c to permit cross-type operators, and add the code to support them for the int2, int4, and int8 opclasses. (To keep this patch digestible, I left the other datatypes for a separate patch.) This improves the usability of btree_gin indexes by allowing them to support the same set of queries that a regular btree index does. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> Discussion: https://postgr.es/m/262624.1738460652@sss.pgh.pa.us
* Break out xxx2yyy_opt_overflow APIs for more datetime conversions.Tom Lane2025-07-03
| | | | | | | | | | | | | | | | | | | | | | | | Previous commits invented timestamp2timestamptz_opt_overflow, date2timestamp_opt_overflow, and date2timestamptz_opt_overflow functions to perform non-error-throwing conversions between datetime types. This patch completes the set by adding timestamp2date_opt_overflow, timestamptz2date_opt_overflow, and timestamptz2timestamp_opt_overflow. In addition, adjust timestamp2timestamptz_opt_overflow so that it doesn't throw error if timestamp2tm fails, but treats that as an overflow case. The situation probably can't arise except with an invalid timestamp value, and I can't think of a way that that would happen except data corruption. However, it's pretty silly to have a function whose entire reason for existence is to not throw errors for out-of-range inputs nonetheless throw an error for out-of-range input. The new APIs are not used in this patch, but will be needed in upcoming btree_gin changes. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> Discussion: https://postgr.es/m/262624.1738460652@sss.pgh.pa.us
* Obtain required table lock during cross-table updates, redux.Tom Lane2025-07-03
| | | | | | | | | | | | | | | | | | | | | | | Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13
* Add tab-completion for ALTER TABLE not-nullsÁlvaro Herrera2025-07-03
| | | | | | | | | | | | | | | The command is: ALTER TABLE x ADD [CONSTRAINT y] NOT NULL z This syntax was added in 18, but I got pushback for getting commit dbf42b84ac7b in 18 (also tab-completion for new syntax) after the feature freeze, so I'll put this in master only for now. Author: Álvaro Herrera <alvherre@kurilemu.de> Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/d4f14c6b-086b-463c-b15f-01c7c9728eab@oss.nttdata.com Discussion: https://postgr.es/m/202505111448.bwbfomrymq4b@alvherre.pgsql
* Remove leftover dead code from commit_ts.h.Fujii Masao2025-07-03
| | | | | | | | | | | | | | Commit 08aa89b3262 removed the COMMIT_TS_SETTS WAL record, leaving xl_commit_ts_set and SizeOfCommitTsSet unused. However, it missed removing these definitions. This commit cleans up the leftover code. Since this is a cleanup rather than a bug fix, it is applied only to the master branch. Author: Andy Fan <zhihuifan1213@163.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/87ecuzmkqf.fsf@163.com
* Fix broken XMLÁlvaro Herrera2025-07-03
| | | | | | | | I messed this up in commit 87251e114967. Per buildfarm member alabio, via Daniel Gustafsson. Discussion: https://postgr.es/m/B94D82D1-7AF4-4412-AC02-82EAA6154957@yesql.se
* doc: Update outdated descriptions of wal_status in pg_replication_slots.Fujii Masao2025-07-03
| | | | | | | | | | | | | | | | | | | | The documentation for pg_replication_slots previously mentioned only max_slot_wal_keep_size as a condition under which the wal_status column could show unreserved or lost. However, since commit be87200, replication slots can also be invalidated due to horizon or wal_level, and since commit ac0e33136ab, idle_replication_slot_timeout can also trigger this state. This commit updates the description of the wal_status column to reflect that max_slot_wal_keep_size is not the only cause of the lost state. Back-patched to v16, where the additional invalidation cases were introduced. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Nisha Moond <nisha.moond412@gmail.com> Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com Backpatch-through: 16
* Prevent creation of duplicate not-null constraints for domainsÁlvaro Herrera2025-07-03
| | | | | | | | | | | This was previously harmless, but now that we create pg_constraint rows for those, duplicates are not welcome anymore. Backpatch to 18. Co-authored-by: jian he <jian.universality@gmail.com> Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://postgr.es/m/CACJufxFSC0mcQ82bSk58sO-WJY4P-o4N6RD2M0D=DD_u_6EzdQ@mail.gmail.com