aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Reject SSL connection if ALPN is used but there's no common protocolHeikki Linnakangas2024-04-29
| | | | | | | | | | | | | | | | | | | | | | | If the client supports ALPN but tries to use some other protocol, like HTTPS, reject the connection in the server. That is surely a confusion of some sort. Furthermore, the ALPN RFC 7301 says: > In the event that the server supports no protocols that the client > advertises, then the server SHALL respond with a fatal > "no_application_protocol" alert. This commit makes the server follow that advice. In the client, specifically check for the OpenSSL error code for the "no_application_protocol" alert. Otherwise you got a cryptic "SSL error: SSL error code 167773280" error if you tried to connect to a non-PostgreSQL server that rejects the connection with "no_application_protocol". ERR_reason_error_string() returns NULL for that code, which frankly seems like an OpenSSL bug to me, but we can easily print a better message ourselves. Reported-by: Jacob Champion Discussion: https://www.postgresql.org/message-id/6aedcaa5-60f3-49af-a857-2c76ba55a1f3@iki.fi
* libpq: Enforce ALPN in direct SSL connectionsHeikki Linnakangas2024-04-29
| | | | | | | | | ALPN is mandatory with direct SSL connections. That is documented, and the server checks it, but libpq was missing the check. Reported-by: Jacob Champion Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com
* libpq: Fix error messages when server rejects SSL or GSSHeikki Linnakangas2024-04-29
| | | | | | | | | | | | | | | | | | | | | | These messages were lost in commit 05fd30c0e7. Put them back. This makes one change in the error message behavior compared to v16, in the case that the server responds to GSSRequest with an error instead of rejecting it with 'N'. Previously, libpq would hide the error that the server sent, assuming that you got the error because the server is an old pre-v12 version that doesn't understand the GSSRequest message. A v11 server sends a "FATAL: unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0" error if you try to connect to it with GSS. That was a reasonable assumption when the feature was introduced, but v12 was released a long time ago and I don't think it's the most probable cause anymore. The attached patch changes things so that libpq prints the error message that the server sent in that case, making the "server responds with error to GSSRequest" case behave the same as the "server responds with error to SSLRequest" case. Reported-by: Peter Eisentraut Discussion: https://www.postgresql.org/message-id/bb3b94da-afc7-438d-8940-cb946e553d9d@eisentraut.org
* Make two-phase tests of ECPG and main suite more concurrent-proofMichael Paquier2024-04-29
| | | | | | | | | | | | | | | | | | | | The ECPG and main 2PC tests have been using rather-generic names for the prepared transactions they generate. This commit switches the 2PC transactions to use more complex GIDs, reducing the risk of naming conflicts. The main 2PC tests also include scans of pg_prepared_xacts that do not apply filters on the GID of the prepared transactions, making it possible to fail the test when any 2PC transaction runs concurrently. The CI has been able to see such failures with an installcheck running the ECPG and the main regression test suites in parallel. The queries on pg_prepared_xacts gain quals to only look after the GIDs generated locally. The race is very hard to reproduce, so no backbatch is done for now. Reported-by: Richard Guo Discussion: https://postgr.es/m/CAMbWs4-mWCGbbE_bne5=AfqjYGDaUZmjCw2+soLjrdNA0xUDFw@mail.gmail.com
* libpq: If ALPN is not used, make PQsslAttribute(conn, "alpn") == ""Heikki Linnakangas2024-04-29
| | | | | | | | | The documentation says that PQsslAttribute(conn, "alpn") returns an empty string if ALPN is not used, but the code actually returned NULL. Fix the code to match the documentation. Reported-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/ZideNHji0G4gxmc3@paquier.xyz
* Revert "Add GUC backtrace_on_internal_error"Peter Eisentraut2024-04-29
| | | | | | | | | | | | This reverts commit a740b213d4b4d3360ad0cac696e47e5ec0eb8864. Subsequent discussion showed that there was interest in a more general facility to configure when server log events would produce backtraces, and this existing limited way couldn't be extended in a compatible way. So the consensus was to revert this for PostgreSQL 17 and reconsider this topic for PostgreSQL 18. Discussion: https://www.postgresql.org/message-id/flat/CAGECzQTChkvn5Xj772LB3%3Dxo2x_LcaO5O0HQvXqobm1xVp6%2B4w%40mail.gmail.com#764bcdbb73e162787e1ad984935e51e3
* Fix documentation and comments on what happens after GSS rejectionHeikki Linnakangas2024-04-28
| | | | | | | | | | | | | | The paragraph in the docs and the comment applied to sslnegotiaton=direct, but not sslnegotiation=requiredirect. In 'requiredirect' mode, negotiated SSL is never used. Move the paragraph in the docs under the description of 'direct' mode, and rephrase it. Also the comment's reference to reusing a plaintext connection was bogus. Authentication failure in plaintext mode only happens after sending the startup packet, so the connection cannot be reused. Reported-by: Jacob Champion Discussion: https://www.postgresql.org/message-id/CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com
* Throw a more on-point error for functions depending on columns.Tom Lane2024-04-28
| | | | | | | | | | | | | | | | | | | | | | | | ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects depending on the column whose type is to be altered. That indeed wasn't possible when this code was written, but it is possible since we introduced new-style SQL function bodies. It's about as difficult to fix this case as it is to fix dependent views, and we've been punting on those for years, so I don't feel too awful about punting for functions too. (I sure wouldn't risk back-patching such code.) So just throw a more user-facing error. Also, adjust some of the existing comments to reflect that these are all pretty much the same issue. (This patch also fixes it so we will tolerate finding such a dependency during ALTER COLUMN SET EXPRESSION; in that, we need not do anything to the function, so no error is wanted. That problem is new in HEAD.) Per bug #18449 from Alexander Lakhin. Back-patch to v14 where we added new-style SQL functions. Discussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org
* Detect more overflows in timestamp[tz]_pl_interval.Tom Lane2024-04-28
| | | | | | | | | | | | | | | | | In commit 25cd2d640 I (tgl) opined that "The additions of the months and microseconds fields could also overflow, of course. However, I believe we need no additional checks there; the existing range checks should catch such cases". This is demonstrably wrong however for the microseconds field, and given that discovery it seems prudent to be paranoid about the months addition as well. Report and patch by Joseph Koshakow. As before, back-patch to all supported branches. (However, the test case doesn't work before v15 because we didn't allow wider-than-int32 numbers in interval literals. A variant test could probably be built that fits within that restriction, but it didn't seem worth the trouble.) Discussion: https://postgr.es/m/CAAvxfHf77sRHKoEzUw9_cMYSpbpNS2C+J_+8Dq4+0oi8iKopeA@mail.gmail.com
* Fix duplicated consecutive words in commentsDavid Rowley2024-04-28
| | | | | | | Also, fix a comment incorrectly referencing the "streaming read API". This was renamed to "read stream" shortly before being committed. Discussion: https://postgr.es/m/CAApHDvq-2Zdqytm_Hf3RmVf0qg5PS9jTFAJ5QTc9xH9pwvwDTA@mail.gmail.com
* Remove redundant JSON parser typedefsAndrew Dunstan2024-04-27
| | | | | | | | | JsonNonTerminal and JsonParserSem were added in commit 3311ea86ed These names of these two enums are not actually used, so there is no need for typedefs. Instead use plain enums to declare the constants. Noticed by Alvaro Herera.
* Small cosmetic fixes in radix tree templateJohn Naylor2024-04-27
| | | | | | | - Bring memory context names in line with other naming - Fix typos, reported off-list by Alexander Lakhin - Remove copy-paste errors from comments - Remove duplicate #undef
* Minor fixes to pg_combinebackup and its documentation.Robert Haas2024-04-26
| | | | | | | | | | | | | | | | | | | | | | The --tablespace-mapping option was specified with required_argument rather than no_argument, which is wrong. Since the actual argument string passed to getopt_long() included "T:", the single-character form of the option still worked, but the long form did not. Repair. The call to getopt_long() erroneously included "P", which doesn't correspond to any supported option. Remove. The help message used "do not" in one place and "don't" in another. Standardize on "do not". The documentation erroneously stated that the tablespace mappings would be applied relative to the pathnames in the first backup specified on the command line, rather than the final one. Fix. Thanks to Tomas Vondra and Daniel Gustafsson for alerting me to these mistakes. Discussion: http://postgr.es/m/CA+TgmoYFznwwaZhHSF1Ze7JeyBv-1yOoSrucKMw37WpF=7RP8g@mail.gmail.com
* pg_combinebackup: Detect checksum mismatches and document limitation.Robert Haas2024-04-25
| | | | | | | | | | | | | | | If not all backups have the same checksum status, but the final backup has checksums enabled, then the output directory may include pages with invalid checksums. Document this limitation and explain how to work around it. In a future release, we may want to teach pg_combinebackup to recompute page checksums when required, but as feature freeze has come and gone, it seems a bit too late to do that for this release. Patch by me, reviewed by Daniel Gustafsson Discussion: http://postgr.es/m/CA+TgmoZugzOSmgkx97u3pc0M7U8LycWvugqoyWBv6j15a4hE5g@mail.gmail.com
* radixtree: Fix SIGSEGV at update of embeddable value to non-embeddable.Masahiko Sawada2024-04-25
| | | | | | | | | | Also, fix a memory leak when updating from non-embeddable to embeddable. Both were unreachable without adding C code. Reported-by: Noah Misch Author: Noah Misch Reviewed-by: Masahiko Sawada, John Naylor Discussion: https://postgr.es/m/20240424210319.4c.nmisch%40google.com
* Post-commit review fixes for slot synchronization.Amit Kapila2024-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow pg_sync_replication_slots() to error out during promotion of standby. This makes the behavior of the SQL function consistent with the slot sync worker. We also ensured that pg_sync_replication_slots() cannot be executed if sync_replication_slots is enabled and the slotsync worker is already running to perform the synchronization of slots. Previously, it would have succeeded in cases when the worker is idle and failed when it is performing sync which could confuse users. This patch fixes another issue in the slot sync worker where SignalHandlerForShutdownRequest() needs to be registered *before* setting SlotSyncCtx->pid, otherwise, the slotsync worker could miss handling SIGINT sent by the startup process(ShutDownSlotSync) if it is sent before worker could register SignalHandlerForShutdownRequest(). To be consistent, all signal handlers' registration is moved to a prior location before we set the worker's pid. Ensure that we clean up synced temp slots at the end of pg_sync_replication_slots() to avoid such slots being left over after promotion. Ensure that ShutDownSlotSync() captures SlotSyncCtx->pid under spinlock to avoid accessing invalid value as it can be reset by concurrent slot sync exit due to an error. Author: Shveta Malik Reviewed-by: Hou Zhijie, Bertrand Drouvot, Amit Kapila, Masahiko Sawada Discussion: https://postgr.es/m/CAJpy0uBefXUS_TSz=oxmYKHdg-fhxUT0qfjASW3nmqnzVC3p6A@mail.gmail.com
* Remove unnecessary code from be_lo_put()Peter Eisentraut2024-04-25
| | | | | | | | | | | | A permission check is performed in be_lo_put() just after returning from inv_open(), but the permission is already checked in inv_open(), so we can remove the second check. This check was added in 8d9881911f0, but then the refactoring in ae20b23a9e7 should have removed it. Author: Yugo NAGATA <nagata@sraoss.co.jp> Discussion: https://www.postgresql.org/message-id/flat/20240424185932.9789628b99a49ec81b020425%40sraoss.co.jp
* Fix the missing table sync due to improper invalidation handling.Amit Kapila2024-04-25
| | | | | | | | | | | | | | | | | | | We missed performing table sync if the invalidation happened while the non-ready tables list was being prepared. This occurs because the sync state was set to valid at the end of non-ready table list preparation irrespective of the invalidations processed while the list is being prepared. Fix it by changing the boolean variable to a tri-state enum and by setting table state to valid only if no invalidations have occurred while the list is being prepared. Reprted-by: Alexander Lakhin Diagnosed-by: Alexander Lakhin Author: Vignesh C Reviewed-by: Hou Zhijie, Alexander Lakhin, Ajin Cherian, Amit Kapila Backpatch-through: 15 Discussion: https://postgr.es/m/711a6afe-edb7-1211-cc27-1bef8239eec7@gmail.com
* Improve comment of DeallocateStmt->isallMichael Paquier2024-04-25
| | | | | | | | | | | | | | This field is not used directly in the code, but it is important for query jumbling to be able to make a difference between a named DEALLOCATE and DEALLOCATE ALL (see bb45156f342c). This behavior is tracked in the regression tests of pg_stat_statements, but the reason why this field is important can be easily missed, as a recent discussion has proved, so let's improve its comment to document the reason why it needs to be around. Wording has been suggested by Tom Lane Discussion: https://postgr.es/m/Zih1ATt37YFda8_p@paquier.xyz
* Add pg_logging_init() calls missing in commit ba3e6e2bcaAndrew Dunstan2024-04-24
| | | | As noticed by Michael Paquier.
* pg_combinebackup: Add --version to --help outputPeter Eisentraut2024-04-24
| | | | (It was already on the man page.)
* pg_combinebackup: Put newer options in consistent order in --help and man pagePeter Eisentraut2024-04-24
|
* Support SSL_R_VERSION_TOO_LOW when using LibreSSLDaniel Gustafsson2024-04-24
| | | | | | | | | | | | | | The SSL_R_VERSION_TOO_LOW error reason is supported in LibreSSL since LibreSSL 3.6.3, shipped in OpenBSD 7.2. SSL_R_VERSION_TOO_HIGH is on the other hand not supported in any version of LibreSSL. Previously we only checked for SSL_R_VERSION_TOO_HIGH and then applied both under that guard since OpenSSL has only ever supported both at the same time. This breaks the check into one per reason to allow SSL_R_VERSION_TOO_LOW to work when using LibreSSL. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/eac70d46-e61c-4d71-a1e1-78e2bfa19485@eisentraut.org
* Support disallowing SSL renegotiation when using LibreSSLDaniel Gustafsson2024-04-24
| | | | | | | | | | | | LibreSSL doesn't support the SSL_OP_NO_RENEGOTIATION macro which is used by OpenSSL, instead it has invented a similar one for client- side renegotiation: SSL_OP_NO_CLIENT_RENEGOTIATION. This has been supported since LibreSSL 2.5.1 which by now can be considered well below the minimum requirement. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/eac70d46-e61c-4d71-a1e1-78e2bfa19485@eisentraut.org
* pg_dump: Put new options in consistent order in --help and man pagePeter Eisentraut2024-04-24
|
* pg_walsummary: Document --version optionPeter Eisentraut2024-04-24
| | | | | It was working, but it was not shown in the --help output or on the man page.
* Remove obsolete symbol from ecpg_config.h.inPeter Eisentraut2024-04-24
| | | | | | | | | | | | | | HAVE_LONG_LONG_INT was not added to ecpg_config.h.in by the meson build system, but rather than add it there, we decided to remove it from the makefile build system, to make both consistent that way. There is no documentation or examples that suggest that the presence of this symbol was publicly advertised, and of course the feature is required by C99 (but we don't necessarily require C99 for ecpg user code). ecpg core code and ecpg tests use the symbol HAVE_LONG_LONG_INT_64 instead, which is still there. Discussion: https://www.postgresql.org/message-id/flat/bf35d032-02fc-4173-9f4f-840999cc3ef3%40eisentraut.org
* Try again to add test coverage for pg_combinebackup w/tablespaces.Robert Haas2024-04-23
| | | | | | | | My previous attempt to add this had to be reverted in commit 82023d47de9e262730b1f9b4ea77fae201a89d0a. I've revised the problematic code a bit; hopefully it is OK now. Discussion: http://postgr.es/m/CA+Tgmobiv1QJR5PEJoDKeZDrJHZFRmi4XmWOqufN49DJj-3e2g@mail.gmail.com
* Post review fixes for test_json_parser test moduleAndrew Dunstan2024-04-23
| | | | | | | | | | | | | . Add missing copytight notices . improve code coverage . put work files in a temp directory in the standard location . improve error checking in C code . indent perl files with perltidy . add some comments per comments from Michael Paquier Discussion: https://postgr.es/m/ZiC3-cdFys4-6xSk@paquier.xyz
* Remove some unnecessary fields from executor nodes.Tom Lane2024-04-23
| | | | | | | | | | | | | | | | | | JsonExprState.input_finfo is only assigned to, never read, and it's really fairly useless since the value can be gotten out of the adjacent input_fcinfo field. Let's remove it before someone starts to depend on it. While here, also remove TidScanState.tss_htup and AggState.combinedproj, which are referenced nowhere. Those should have been removed by the commits that caused them to become disused, but were not. I don't think a catversion bump is necessary here, since plan trees are never stored on disk. Matthias van de Meent Discussion: https://postgr.es/m/CAEze2WjsY4d0TBymLNGK4zpttUcg_YZaTjyWz2VfDUV6YH8wXQ@mail.gmail.com
* Fix code for probing availability of AVX-512.Nathan Bossart2024-04-23
| | | | | | | | | | | | | | | | | | | This commit fixes a few things: * Instead of checking for CPU support of the "xsave" extension, we need to check for OS support of XGETBV instructions via the "osxsave" flag. * We must check that additional XCR0 bits are set to be sure the ZMM registers are fully enabled. * We should use the recommended ordering of steps. Specifically, we need to check that the ZMM registers are enabled prior to checking for AVX-512 via CPUID. In passing, split this code into separate functions to improve readability. Reported-by: Andrew Kane Reviewed-by: Akash Shankaran, Raghuveer Devulapalli Discussion: https://postgr.es/m/20240418024459.GA3385227%40nathanxps13
* Improve "out of range" error messages for GUCs.Tom Lane2024-04-23
| | | | | | | If the GUC has a unit, label the minimum and maximum values with the unit explicitly. Per suggestion from Jian He. Discussion: https://postgr.es/m/CACJufxFJo6FyVg9W8yvNAxbjP+EJ9wieE9d9vw5LpPzyLnLLOQ@mail.gmail.com
* Fix the handling of the failover option in subscription commands.Amit Kapila2024-04-23
| | | | | | | | | | | | | Do not allow ALTER SUBSCRIPTION ... SET (failover = on|off) in a transaction block as the changed failover option of the slot can't be rolled back. For the same reason, we refrain from altering the replication slot's failover property if the subscription is created with a valid slot_name and create_slot=false. Reprted-by: Kuroda Hayato Author: Hou Zhijie Reviewed-by: Shveta Malik, Bertrand Drouvot, Kuroda Hayato Discussion: https://postgr.es/m/OS0PR01MB57165542B09DFA4943830BF294082@OS0PR01MB5716.jpnprd01.prod.outlook.com
* Remove unneeded nbtree array preprocessing assert.Peter Geoghegan2024-04-22
| | | | | | | | | | | | | | | | | | | | | | | | Certain cases involving the use of cursors had assertion failures within _bt_preprocess_keys's recently added no-op return path. The assertion in question made the faulty assumption that a second or third call to _bt_preprocess_keys (within the same btrescan) could only happen when another scheduled primitive index scan was just about to begin. It would be possible to address the problem by only allowing scans that have array keys to take the new no-op path, forcing affected cases to perform redundant preprocessing work. It seems simpler to just remove the assertion, and reframe the no-op path as a more general mechanism. Take this simpler approach. The important underlying principle is that we only need to perform preprocessing once per btrescan (at most). This is expected regardless of whether or not the scan happens to have array keys. Oversight in commit 1b134ca5, which enhanced nbtree ScalarArrayOp execution. Reported-By: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/ef0f7c8b-a6fa-362e-6fd6-054950f947ca@gmail.com
* Update src/common/unicode/.gitignorePeter Eisentraut2024-04-22
| | | | for new downloaded files and new build results.
* Update Unicode data to CLDR 45Peter Eisentraut2024-04-22
| | | | No actual changes result.
* Fix dumps of partitioned tables with table AMsMichael Paquier2024-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pg_dump/restore failed to properly set the table access method for partitioned tables, as it relies on SET queries that would change default_table_access_method. However, SET affects only tables and materialized views, not partitioned tables which would always be restored with their pg_class.relam set to 0, losing their table AM set by either a CREATE TABLE .. USING or by a ALTER TABLE .. SET ACCESS METHOD. Appending a USING clause to the definition of CREATE TABLE is not possible as users may specify --no-table-access-method at restore or for a dump, meaning that the table AM portions may have to be skipped. Rather than SET, the solution used by this commit is to generate an extra ALTER TABLE .. SET ACCESS METHOD when restoring a partitioned table, based on the table AM set in its TOC entry. The choice of using a SET query or an ALTER TABLE query for a relation requires the addition of the relkind to the TOC entry to be able to choose between one or the other. Note that using ALTER TABLE SET ACCESS METHOD on a relation with physical storage would require a full rewrite, which would be costly for one. This also creates problems with binary upgrades where the rewrite would not be able to keep the OID of the relation consistent across the upgrade. This commit would normally require a protocol bump, but a45c78e3284b has already done one for this release cycle. Regression tests are adjusted with the new expected output, with some tweaks for the table AMs of the partitions to make the output more readable. Issue introduced by 374c7a229042, that has added support for table AMs in partitioned tables. Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/Zh4JLSvvtQgBJZkZ@paquier.xyz
* Remove overzealous array element type assertion.Peter Geoghegan2024-04-21
| | | | | | | | | | | This led to spurious assertion failures in certain scenarios involving pseudo types. Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution. Reported-By: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/CAMbWs48f5rDOwxaT76Zd40m7n9iGZQcjEk7vG_5p3YWNh6oPfA@mail.gmail.com
* createdb: compare strategy case-insensitiveTomas Vondra2024-04-21
| | | | | | | | | | | | | | | | | | | When specifying the createdb strategy, the documentation suggests valid options are FILE_COPY and WAL_LOG, but the code does case-sensitive comparison and accepts only "file_copy" and "wal_log" as valid. Fixed by doing a case-insensitive comparison using pg_strcasecmp(), same as for other string parameters nearby. While at it, apply fmtId() to a nearby "locale_provider". This already did the comparison in case-insensitive way, but the value would not be double-quoted, confusing the parser and the error message. Backpatch to 15, where the strategy was introduced. Backpatch-through: 15 Reviewed-by: Tom Lane Discussion: https://postgr.es/m/90c6913a-1dd2-42b4-8365-ce3b09c39b17@enterprisedb.com
* Remove resowner_private.hMichael Paquier2024-04-20
| | | | | | | | | This header is not used since the refactoring of resource owners done in b8bff07daa85, and all the functions declared in it became (well, mostly) static inline local to each resowner kind's code path. Author: Xing Guo Discussion: https://postgr.es/m/CACpMh+BFmtK5Z=b6PvH4HLKhUpWa_VtRTZSrB4-yK-tQejpWGw@mail.gmail.com
* Revert recent ill-advised test case changes.Robert Haas2024-04-19
| | | | | | | | | | | | | Commit 6bf5c42b5546984df29289918f952e6211069c54 cannot work on Windows, because it lacks symlink support. While the bug fix in commit cd64dc42d1e1b03e57e6ba3d316e4f9dec52a78d is correct as far as I know, the test case changes depend on the previous commit, so this will have to live without test coverage until we can come up with a better solution. Commit fa7036dd6644d13233b475874a94754a5903e35a was a test case bug fix on top of those two, to prevent failures on Linux, so that has to come out as well. Per the buildfarm, CI, and Thomas Munro.
* Use tempdir_short instead of tempdir.Robert Haas2024-04-19
| | | | | | | | | | | | | | | | | After cd64dc42d1e1b03e57e6ba3d316e4f9dec52a78d, a significant percentage of the buildfarm got unhappy, because pg_basebackup chokes if it tries to create a tarfile with symlink more than 99 characters in length. To try to fix that problem, use tempdir_short instead of tempdir, as we do in pg_verifybackup's 003_corruption.pl. There's a more complicated workaround for the same issue in pg_basebackup's 010_pg_basebackup.pl, but I'm not clear whether there's any reason to do it that way here. For now, let's try this, to at least get the buildfarm green again. A better long-term fix would be to figure out how to generate tar files containing long symlinks, but that will have to wait for another time.
* pg_combinebackup: Fix incorrect tablespace handling.Robert Haas2024-04-19
| | | | | | | | | | | The previous coding mangled the pathname calculation for incremental files located in user-defined tablespaces. Enhance the test cases to cover such cases, as I should have done originally. Thanks to Andres Freund for alerting me to the lack of test coverage. Discussion: http://postgr.es/m/CA+TgmoYdXTjo9iQeoipTccDpWZzvBNS6EndY2uARM+T4yG_yDg@mail.gmail.com
* Make PostgreSQL::Test::Cluster::init_from_backup handle tablespaces.Robert Haas2024-04-19
| | | | | | | | | | This commit doesn't use this infrastructure for anything new, although it does adapt 010_pg_basebackup.pl to use it. However, a future commit will use this to improve test coverage for pg_combinebackup. Patch by me, reviewed (but not fully endorsed) by Andres Freund. Discussion: http://postgr.es/m/CA+TgmoYdXTjo9iQeoipTccDpWZzvBNS6EndY2uARM+T4yG_yDg@mail.gmail.com
* Add missing index_insert_cleanup callsTomas Vondra2024-04-19
| | | | | | | | | | | | | | | | | | | | | | | The optimization for inserts into BRIN indexes added by c1ec02be1d79 relies on a cache that needs to be explicitly released after calling index_insert(). The commit however failed to invoke the cleanup in validate_index(), which calls index_insert() indirectly through table_index_validate_scan(). After inspecting index_insert() callers, it seems unique_key_recheck() is missing the call too. Fixed by adding the two missing index_insert_cleanup() calls. The commit does two additional improvements. The aminsertcleanup() signature is modified to have the index as the first argument, to make it more like the other AM callbacks. And the aminsertcleanup() callback is invoked even if the ii_AmCache is NULL, so that it can decide if the cleanup is necessary. Author: Alvaro Herrera, Tomas Vondra Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/202401091043.e3nrqiad6gb7@alvherre.pgsql
* Fix a couple typos in BRIN codeTomas Vondra2024-04-19
| | | | | | | | Typos introduced by commits c1ec02be1d79, b43757171470 and dae761a87eda. Author: Alvaro Herrera Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/202401091043.e3nrqiad6gb7@alvherre.pgsql
* Better handle indirect constraint dropsAlvaro Herrera2024-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible for certain cases to remove not-null constraints without maintaining the attnotnull in its correct state; for example if you drop a column that's part of the primary key, and the other columns of the PK don't have not-null constraints, then we should reset the attnotnull flags for those other columns; up to this commit, we didn't. Handle those cases better by doing the attnotnull reset in RemoveConstraintById() instead of in dropconstraint_internal(). However, there are some cases where we must not do so. For example if those other columns are in replica identity indexes or are generated identity columns, we must keep attnotnull set, even though it results in the catalog inconsistency that no not-null constraint supports that. Because the attnotnull reset now happens in more places than before, for instance when a column of the primary key changes type, we need an additional trick to reinstate it as necessary. Introduce a new alter-table pass that does this, which needs simply reschedule some AT_SetAttNotNull subcommands that were already being generated and ignored. Because of the exceptions in which attnotnull is not reset noted above, we also include a pg_dump hack to include a not-null constraint when the attnotnull flag is set even if no pg_constraint row exists. This part is undesirable but necessary, because failing to handle the case can result in unrestorable dumps. Reported-by: Tender Wang <tndrwang@gmail.com> Co-authored-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://postgr.es/m/CAHewXN=hMbNa3d43NOR=OCgdgpTt18S-1fmueCoEGesyeK4bqw@mail.gmail.com
* Use macro NUM_MERGE_MATCH_KINDS instead of '3' in MERGE code.Dean Rasheed2024-04-19
| | | | | | | | Code quality improvement for 0294df2f1f84. Aleksander Alekseev, reviewed by Richard Guo. Discussion: https://postgr.es/m/CAJ7c6TMsiaV5urU_Pq6zJ2tXPDwk69-NKVh4AMN5XrRiM7N%2BGA%40mail.gmail.com
* Remove unused function prototypeDaniel Gustafsson2024-04-19
| | | | | | | | Commit aafc05de1bf5 removed StartSlotSyncWorker() but mistakenly left the prototype in slotsync.h. Fix by removing. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/3F577953-A29E-4722-98AD-2DA9EFF2CBB8@yesql.se
* Fix incorrect parameter name in prototypeDaniel Gustafsson2024-04-19
| | | | | | | | | The function declaration for select_next_encryption_method use the variable name have_valid_connection, so fix the prototype in the header to match that. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/3F577953-A29E-4722-98AD-2DA9EFF2CBB8@yesql.se
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 15:02:19 +0000