aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* 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
* Fix bogus grammar for a CREATE CONSTRAINT TRIGGER errorÁlvaro Herrera2025-07-03
| | | | | | | | | | | | | | | | | | | | If certain constraint characteristic clauses (NO INHERIT, NOT VALID, NOT ENFORCED) are given to CREATE CONSTRAINT TRIGGER, the resulting error message is ERROR: TRIGGER constraints cannot be marked NO INHERIT which is a bit silly, because these aren't "constraints of type TRIGGER". Hardcode a better error message to prevent it. This is a cosmetic fix for quite a fringe problem with no known complaints from users, so no backpatch. While at it, silently accept ENFORCED if given. Author: Amul Sul <sulamul@gmail.com> Reviewed-by: jian he <jian.universality@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://postgr.es/m/CAAJ_b97hd-jMTS7AjgU6TDBCzDx_KyuKxG+K-DtYmOieg+giyQ@mail.gmail.com Discussion: https://postgr.es/m/CACJufxHSp2puxP=q8ZtUGL1F+heapnzqFBZy5ZNGUjUgwjBqTQ@mail.gmail.com
* Refactor subtype field of AlterDomainStmtMichael Paquier2025-07-03
| | | | | | | | | | | | | | | | | AlterDomainStmt.subtype used characters for its subtypes of commands, SET|DROP DEFAULT|NOT NULL and ADD|DROP|VALIDATE CONSTRAINT, which were hardcoded in a couple of places of the code. The code is improved by using an enum instead, with the same character values as the original code. Note that the field was documented in parsenodes.h and that it forgot to mention 'V' (VALIDATE CONSTRAINT). Author: Quan Zongliang <quanzongliang@yeah.net> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/41ff310b-16bd-44b9-a3ef-97e20f14b709@yeah.net
* doc: Remove incorrect note about wal_status in pg_replication_slots.Fujii Masao2025-07-03
| | | | | | | | | | | | | | | The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Nisha Moond <nisha.moond412@gmail.com> Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701d89@oss.nttdata.com Backpatch-through: 13
* Support multi-line headers in COPY FROM command.Fujii Masao2025-07-03
| | | | | | | | | | | The COPY FROM command now accepts a non-negative integer for the HEADER option, allowing multiple header lines to be skipped. This is useful when the input contains multi-line headers that should be ignored during data import. Author: Shinya Kato <shinya11.kato@gmail.com> Co-authored-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp> Discussion: https://postgr.es/m/CAOzEurRPxfzbxqeOPF_AGnAUOYf=Wk0we+1LQomPNUNtyZGBZw@mail.gmail.com
* Improve checks for GUC recovery_target_timelineMichael Paquier2025-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | Currently check_recovery_target_timeline() converts any value that is not "current", "latest", or a valid integer to 0. So, for example, the following configuration added to postgresql.conf followed by a startup: recovery_target_timeline = 'bogus' recovery_target_timeline = '9999999999' ... results in the following error patterns: FATAL: 22023: recovery target timeline 0 does not exist FATAL: 22023: recovery target timeline 1410065407 does not exist This is confusing, because the server does not reflect the intention of the user, and just reports incorrect data unrelated to the GUC. The origin of the problem is that we do not perform a range check in the GUC value passed-in for recovery_target_timeline. This commit improves the situation by using strtou64() and by providing stricter range checks. Some test cases are added for the cases of an incorrect, an upper-bound and a lower-bound timeline value, checking the sanity of the reports based on the contents of the server logs. Author: David Steele <david@pgmasters.net> Discussion: https://postgr.es/m/e5d472c7-e9be-4710-8dc4-ebe721b62cea@pgbackrest.org
* Enable use of Memoize for ANTI joinsRichard Guo2025-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we do not support Memoize for SEMI and ANTI joins because nested loop SEMI/ANTI joins do not scan the inner relation to completion, which prevents Memoize from marking the cache entry as complete. One might argue that we could mark the cache entry as complete after fetching the first inner tuple, but that would not be safe: if the first inner tuple and the current outer tuple do not satisfy the join clauses, a second inner tuple matching the parameters would find the cache entry already marked as complete. However, if the inner side is provably unique, this issue doesn't arise, since there would be no second matching tuple. That said, this doesn't help in the case of SEMI joins, because a SEMI join with a provably unique inner side would already have been reduced to an inner join by reduce_unique_semijoins. Therefore, in this patch, we check whether the inner relation is provably unique for ANTI joins and enable the use of Memoize in such cases. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com> Reviewed-by: Andrei Lepikhov <lepihov@gmail.com> Discussion: https://postgr.es/m/CAMbWs48FdLiMNrmJL-g6mDvoQVt0yNyJAqMkv4e2Pk-5GKCZLA@mail.gmail.com
* Add InjectionPointList() to retrieve list of injection pointsMichael Paquier2025-07-03
| | | | | | | | | | | | | | | | | | This routine has come as a useful piece to be able to know the list of injection points currently attached in a system. One area would be to use it in a set-returning function, or just let out-of-core code play with it. This hides the internals of the shared memory array lookup holding the information about the injection points (point name, library and function name), allocating the result in a palloc'd List consumable by the caller. Reviewed-by: Jeff Davis <pgsql@j-davis.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Rahila Syed <rahilasyed90@gmail.com> Discussion: https://postgr.es/m/Z_xYkA21KyLEHvWR@paquier.xyz Discussion: https://postgr.es/m/aBG2rPwl3GE7m1-Q@paquier.xyz
* Correctly copy the target host identification in PQcancelCreate.Tom Lane2025-07-02
| | | | | | | | | | | | | | | PQcancelCreate failed to copy struct pg_conn_host's "type" field, instead leaving it zero (a/k/a CHT_HOST_NAME). This seemingly has no great ill effects if it should have been CHT_UNIX_SOCKET instead, but if it should have been CHT_HOST_ADDRESS then a null-pointer dereference will occur when the cancelConn is used. Bug: #18974 Reported-by: Maxim Boguk <maxim.boguk@gmail.com> Author: Sergei Kornilov <sk@zsrv.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18974-575f02b2168b36b3@postgresql.org Backpatch-through: 17
* Fix cross-version upgrade test breakage from commit fe07100e82.Nathan Bossart2025-07-02
| | | | | | | | | | | | | | | | | | | In commit fe07100e82, I renamed a couple of functions in test_dsm_registry to make it clear what they are testing. However, the buildfarm's cross-version upgrade tests run pg_upgrade with the test modules installed, so this caused errors like: ERROR: could not find function "get_val_in_shmem" in file ".../test_dsm_registry.so" To fix, revert those renames. I could probably get away with only un-renaming the C symbols, but I figured I'd avoid introducing function name mismatches. Also, AFAICT the buildfarm's cross-version upgrade tests do not run the test module tests post-upgrade, else we'll need to properly version the extension. Per buildfarm member crake. Discussion: https://postgr.es/m/aGVuYUNW23tStUYs%40nathan
* Make more use of RELATION_IS_OTHER_TEMP().Nathan Bossart2025-07-02
| | | | | | | | A few places were open-coding it instead of using this handy macro. Author: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://postgr.es/m/CAEG8a3LjTGJcOcxQx-SUOGoxstG4XuCWLH0ATJKKt_aBTE5K8w%40mail.gmail.com
* Add GetNamedDSA() and GetNamedDSHash().Nathan Bossart2025-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Presently, the dynamic shared memory (DSM) registry only provides GetNamedDSMSegment(), which allocates a fixed-size segment. To use the DSM registry for more sophisticated things like dynamic shared memory areas (DSAs) or a hash table backed by a DSA (dshash), users need to create a DSM segment that stores various handles and LWLock tranche IDs and to write fairly complicated initialization code. Furthermore, there is likely little variation in this initialization code between libraries. This commit introduces functions that simplify allocating a DSA or dshash within the DSM registry. These functions are very similar to GetNamedDSMSegment(). Notable differences include the lack of an initialization callback parameter and the prohibition of calling the functions more than once for a given entry in each backend (which should be trivially avoidable in most circumstances). While at it, this commit bumps the maximum DSM registry entry name length from 63 bytes to 127 bytes. Also note that even though one could presumably detach/destroy the DSAs and dshashes created in the registry, such use-cases are not yet well-supported, if for no other reason than the associated DSM registry entries cannot be removed. Adding such support is left as a future exercise. The test_dsm_registry test module contains tests for the new functions and also serves as a complete usage example. Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Reviewed-by: Sami Imseih <samimseih@gmail.com> Reviewed-by: Florents Tselai <florents.tselai@gmail.com> Reviewed-by: Rahila Syed <rahilasyed90@gmail.com> Discussion: https://postgr.es/m/aEC8HGy2tRQjZg_8%40nathan
* Update obsolete row compare preprocessing comments.Peter Geoghegan2025-07-02
| | | | | | | | | | | Restore nbtree preprocessing comments describing how we mark nbtree row compare members required to how they were prior to 2016 bugfix commit a298a1e0. Oversight in commit bd3f59fd, which made nbtree preprocessing revert to the original 2006 rules, but neglected to revert these comments. Backpatch-through: 18
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 15:50:19 +0000