aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Add comments and a missing CHECK_FOR_INTERRUPTS in ts_headline.Tom Lane2022-11-21
| | | | | | | | | | | | | | | | I just spent an annoying amount of time reverse-engineering the 100%-undocumented API between ts_headline and the text search parser's prsheadline function. Add some commentary about that while it's fresh in mind. Also remove some unused macros in wparser_def.c. While at it, I noticed that when commit 78e73e875 added a CHECK_FOR_INTERRUPTS call in TS_execute_recurse, it missed doing so in the parallel function TS_phrase_execute, which surely needs one just as much. Back-patch because of the missing CHECK_FOR_INTERRUPTS. Might as well back-patch the rest of this too.
* Fix mislabeling of PROC_QUEUE->links as PGPROC, fixing UBSan on 32bitAndres Freund2022-11-19
| | | | | | | | | | | | | | | | | | | | | | | ProcSleep() used a PGPROC* variable to point to PROC_QUEUE->links.next, because that does "the right thing" with SHMQueueInsertBefore(). While that largely works, it's certainly not correct and unnecessary - we can just use SHM_QUEUE* to point to the insertion point. Noticed when testing a 32bit of postgres with undefined behavior sanitizer. UBSan noticed that sometimes the supposed PGPROC wasn't sufficiently aligned (required since 46d6e5f5679, ensured indirectly, via ShmemAllocRaw() guaranteeing cacheline alignment). For now fix this by using a SHM_QUEUE* for the insertion point. Subsequently we should replace all the use of PROC_QUEUE and SHM_QUEUE with ilist.h, but that's a larger change that we don't want to backpatch. Backpatch to all supported versions - it's useful to be able to run postgres under UBSan. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20221117014230.op5kmgypdv2dtqsf@awork3.anarazel.de Backpatch: 11-
* Disable debug_discard_caches in test_oat_hooks test.Tom Lane2022-11-19
| | | | | | | | | | | | The test output varies when debug_discard_caches is enabled, because that causes extra executions of recomputeNamespacePath. Maybe putting a hook in that was a bad idea, but as a stopgap, just turn off debug_discard_caches in this test. Per buildfarm (now that we have debug_discard_caches coverage again). Back-patch to v15 where this module was added. Discussion: https://postgr.es/m/2267406.1668804934@sss.pgh.pa.us
* Doc: sync src/tutorial/basics.source with SGML documentation.Tom Lane2022-11-19
| | | | | | | | | | | basics.source is supposed to be pretty closely in step with the examples in chapter 2 of the tutorial, but I forgot to update it in commit f05a5e000. Fix that, and adjust a couple of other discrepancies that had crept in over time. (I notice that advanced.source is nowhere near being in sync with chapter 3, but I lack the ambition to do something about that right now.)
* Fix version comparison in Version.pmAndrew Dunstan2022-11-18
| | | | | | | | | | | | | Version strings with unequal numbers of parts were being compared incorrectly. We cure this by treating a missing part in the shorter version as 0. per complaint from Jehan-Guillaume de Rorthais, but the fix is mine, not his. Discussion: https://postgr.es/m/20220628225325.53d97b8d@karst Backpatch to release 14 where this code was introduced.
* Fix MERGE tuple count with DO NOTHINGAlvaro Herrera2022-11-17
| | | | | | | | | | Reporting tuples for which nothing is done is useless and goes against the documented behavior, so don't do it. Backpatch to 15. Reported by: Luca Ferrari Discussion: https://postgr.es/m/CAKoxK+42MmACUh6s8XzASQKizbzrtOGA6G1UjzCP75NcXHsiNw@mail.gmail.com
* Account for IPC::Run::result() Windows behavior change.Noah Misch2022-11-17
| | | | | | | | | This restores compatibility with the not-yet-released successor of version 20220807.0. Back-patch to 9.4, which introduced this code. Reviewed by Andrew Dunstan. Discussion: https://postgr.es/m/20221117061805.GA4020280@rfd.leadboat.com
* Fix outdated comment in ExecDeleteAlvaro Herrera2022-11-17
| | | | | | | | This commend references a struct that disappeared before MERGE was merged ... and ExecDelete is not called by the committed MERGE anyway. Revert to the original wording. Backpatch to 15
* doc: Fix wording of MERGE actions in READMEDaniel Gustafsson2022-11-17
| | | | | | | | | | | | UPDATE was listed twice and DELETE was omitted, replace one UPDATE with DELETE instead. Backpatch through v15 where MERGE was added. Author: Myo Wai Thant <myo.waithant@fujitsu.com> Reviewed-by: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/OSAPR01MB43247E46931E9E9CFC4AA0F29A079@OSAPR01MB4324.jpnprd01.prod.outlook.com Backpatch-through: 15
* Fix cleanup lock acquisition in SPLIT_ALLOCATE_PAGE replay.Amit Kapila2022-11-14
| | | | | | | | | | | | | | | | During XLOG_HASH_SPLIT_ALLOCATE_PAGE replay, we were checking for a cleanup lock on the new bucket page after acquiring an exclusive lock on it and raising a PANIC error on failure. However, it is quite possible that checkpointer can acquire the pin on the same page before acquiring a lock on it, and then the replay will lead to an error. So instead, directly acquire the cleanup lock on the new bucket page during XLOG_HASH_SPLIT_ALLOCATE_PAGE replay operation. Reported-by: Andres Freund Author: Robert Haas Reviewed-By: Amit Kapila, Andres Freund, Vignesh C Backpatch-through: 11 Discussion: https://postgr.es/m/20220810022617.fvjkjiauaykwrbse@awork3.anarazel.de
* Use installed postgresql.conf.sample for GUC sanity TAP testAndrew Dunstan2022-11-13
| | | | | | | | | | | The current code looks for the sample file in the source directory, but it seems better to test against the installed sample file. Backpatch to release 15 where the test was introduced. Discussion: https://postgr.es/m/73eea68e-3b6f-5f63-6024-25ed26b52016@dunslane.net Reviewed by Tom Lane, Alvaro Herrera, Michael Paquier.
* Make PostgreSQL::Test::Cluster::config_data more flexibleAndrew Dunstan2022-11-13
| | | | | | | | | | | | | | | | | | Currently this only allows for one argument, which must be present, and always returns a single string. With this change the following now all work: $all_config = $node->config_data; %config_map = ($node->config_data); $incdir = $node->config_data('--include-dir'); ($incdir, $sharedir) = $node->config_data( qw(--include-dir --share-dir)); Backpatch to release 15 where this was introduced. Discussion: https://postgr.es/m/73eea68e-3b6f-5f63-6024-25ed26b52016@dunslane.net Reviewed by Tom Lane, Alvaro Herrera, Michael Paquier.
* If wait_for_catchup fails under has_wal_read_bug, skip balance of test.Noah Misch2022-11-12
| | | | | | | | | | | | | Test files should now ignore has_wal_read_bug() so long as wait_for_catchup() is their only known way of reaching the bug. That's at least five files today, a number expected to grow over time. This commit removes skip logic from three. By doing so, systems having the bug regain the ability to catch other kinds of defects via those three tests. The other two, 002_databases.pl and 031_recovery_conflict.pl, have been unprotected. Back-patch to v15, where done_testing() first became our standard. Discussion: https://postgr.es/m/20221030031639.GA3082137@rfd.leadboat.com
* Fix theoretical torn page hazard.Jeff Davis2022-11-11
| | | | | | | | | | | | | | | | | | | | | | | | The original report was concerned with a possible inconsistency between the heap and the visibility map, which I was unable to confirm. The concern has been retracted. However, there did seem to be a torn page hazard when using checksums. By not setting the heap page LSN during redo, the protections of minRecoveryPoint were bypassed. Fixed, along with a misleading comment. It may have been impossible to hit this problem in practice, because it would require a page tear between the checksum and the flags, so I am marking this as a theoretical risk. But, as discussed, it did violate expectations about the page LSN, so it may have other consequences. Backpatch to all supported versions. Reported-by: Konstantin Knizhnik Reviewed-by: Konstantin Knizhnik Discussion: https://postgr.es/m/fed17dac-8cb8-4f5b-d462-1bb4908c029e@garret.ru Backpatch-through: 11
* Fix alter_table.sql test case to test what it claims to.Tom Lane2022-11-10
| | | | | | | | | | | | | | The stanza "SET STORAGE may need to add a TOAST table" does not test what it's supposed to, and hasn't done so since we added the ability to store constant column default values as metadata. We need to use a non-constant default to get the expected table rewrite to actually happen. Fix that, and add the missing checks that would have exposed the problem to begin with. Noted while reviewing a patch that made changes in this test case. Back-patch to v11 where the problem came in.
* Re-allow building on Microsoft Visual Studio 2013.Tom Lane2022-11-10
| | | | | | | | | | | | | | | | | | In commit 450ee7012 I supposed that all platforms we now care about have snprintf(), since that's required by C99. Turns out that Microsoft did not get around to adding that until VS2015. We've dropped support for VS2013 as of HEAD (cf 6203583b7), but not in the back branches, so add a hack for this in the back branches only. There's no easy shortcut to an exact emulation of standard snprintf in VS2013, but fortunately we don't need one: this code was just fine with using sprintf before 450ee7012, so we can make it do so again on that platform (and any others where the problem might crop up). Per bug #17681 from Daisuke Higuchi. Back-patch to v12, like the previous patch. Discussion: https://postgr.es/m/17681-485ba2ec13e7f392@postgresql.org
* Fix comments atop ReorderBufferAddInvalidations.Amit Kapila2022-11-10
| | | | | | | | | | | The comments atop seem to indicate that we always accumulate invalidation messages in a top-level transaction which is neither required nor matches with the code. Author: Amit Kapila Reviewd by: Masahiko Sawada Backpatch-through: 14, where it was introduced in commit c55040ccd0 Discussion: https://postgr.es/m/CAA4eK1LxGgnUroPz8STb6OfjVU1yaHoSA+T63URwmGCLdMJ0LA@mail.gmail.com
* Fix comment of SimpleLruInit() in slru.cMichael Paquier2022-11-10
| | | | | | | | | | sync_handler was not mentioned in the comment block of the function. Oversight in dee663f. Author: Aleksander Alekseev Discussion: https://postgr.es/m/CAJ7c6TPUd9BwNY47TtMxaijLHSbyHNdhu=kvbGnvO_bi+oC6_Q@mail.gmail.com Backpatch-through: 14
* Apply a better fix to mdunlinkfork().Tom Lane2022-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the stopgap fix I made in 0e758ae89 with a cleaner one. The real problem with 4ab5dae94 is that it contorted this function's logic substantially, by introducing a third code path that required different behavior in the function's main loop. That seems quite unnecessary on closer inspection: the new IsBinaryUpgrade case can just share the behavior of the other immediate-unlink cases. Hence, revert 4ab5dae94 and most of 0e758ae89 (keeping the latter's save/restore errno fix), and add IsBinaryUpgrade to the set of conditions tested to choose immediate unlink. Also fix some additional places with sloppy handling of errno, to ensure we have an invariant that we always continue processing after any non-ENOENT failure of do_truncate. I doubt that that's fixing any bug of field importance, so I don't feel it necessary to back-patch; but we might as well get it right while we're here. Also improve the comments, which had drifted a bit from what the code actually does, and neglected to mention some important considerations. Back-patch to v15, not because this is fixing any bug but because it doesn't seem like a good idea for v15's mdunlinkfork logic to be significantly different from both v14 and v16. Discussion: https://postgr.es/m/3797575.1667924888@sss.pgh.pa.us
* Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.Tom Lane2022-11-09
| | | | | | | | | | | | | Add a little to the header comments for these functions to make it clearer what guarantees about commit behavior are provided to callers. (See commit f92944137 for context.) Although this is only a comment change, it's really documentation aimed at authors of extensions, so it seems appropriate to back-patch. Yugo Nagata and Tom Lane, per further discussion of bug #17434. Discussion: https://postgr.es/m/17434-d9f7a064ce2a88a3@postgresql.org
* Translation updatesAlvaro Herrera2022-11-07
| | | | | Source-Git-URL: ssh://git@git.postgresql.org/pgtranslation/messages.git Source-Git-Hash: 0a578288026cfaae6b3d120b3ecf719aaa94dfdc
* Fix failure to remove non-first segments of temporary tables.Tom Lane2022-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4ab5dae94 broke mdunlinkfork's logic for removing additional segments of a multi-gigabyte table, because it neglected to advance "segno" after unlinking the first segment, in the code path where it chooses to unlink that one immediately. Then the main remove loop gets ENOENT at segment zero and figures it's done, so we never remove whatever additional segments might exist. The main problem here is with large temporary tables, but WAL replay of a drop of a large regular table would also fail to remove extra segments. The third case where this path is taken is for non-main forks; but I doubt it matters for those since they probably never exceed 1GB. The simplest fix is just to increment segno after that unlink(). (Probably this logic could do with a more thorough rethink, but not with mere hours to go before 15.1 wraps.) While here, also fix an incautious assumption that register_forget_request cannot change errno. I don't think that that has any really bad consequences, as we'd end up trying to unlink the zero'th segment either way, but it greatly complicates reasoning about what could happen here. Also make a couple of other cosmetic fixes. Per bug #17679 from Balazs Szilfai. Back-patch into v15, as the faulty patch was. Discussion: https://postgr.es/m/17679-1095d04450cf6a6e@postgresql.org
* Translation updatesPeter Eisentraut2022-11-07
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: f491e594cbaa7be0f786199e48f44bf0d55c9c8b
* Fix CREATE DATABASE so we can pg_upgrade DBs with OIDs above 2^31.Tom Lane2022-11-04
| | | | | | | | | | | Commit aa0105141 repeated one of the oldest mistakes in our book: thinking that OID is the same as int32. It isn't of course, and unsurprisingly the first person who came along with a database OID above 2 billion broke it. Repair. Per bug #17677 from Sergey Pankov. Back-patch to v15. Discussion: https://postgr.es/m/17677-a99fa067d7ed71c9@postgresql.org
* Correct error message for row-level triggers with transition tables on ↵Etsuro Fujita2022-11-04
| | | | | | | | | | | | | | | partitioned tables. "Triggers on partitioned tables cannot have transition tables." is incorrect as we allow statement-level triggers on partitioned tables to have transition tables. This has been wrong since commit 86f575948; back-patch to v11 where that commit came in. Reviewed by Tom Lane. Discussion: https://postgr.es/m/CAPmGK17gk4vXLzz2iG%2BG4LWRWCoVyam70nZ3OuGm1hMJwDrhcg%40mail.gmail.com
* Create FKs properly when attaching table as partitionAlvaro Herrera2022-11-03
| | | | | | | | | | | | | | | | | | | | | | Commit f56f8f8da6af added some code in CloneFkReferencing that's way too lax about a Constraint node it manufactures, not initializing enough struct members -- initially_valid in particular was forgotten. This causes some FKs in partitions added by ALTER TABLE ATTACH PARTITION to be marked as not validated. Set initially_valid true, which fixes the bug. While at it, make the struct initialization more complete. Very similar code was added in two other places by the same commit; make them all follow the same pattern for consistency, though no bugs are apparent there. This bug has never been reported: I only happened to notice while working on commit 614a406b4ff1. The test case that was added there with the improper result is repaired. Backpatch to 12. Discussion: https://postgr.es/m/20221005105523.bhuhkdx4olajboof@alvherre.pgsql
* Avoid crash after function syntax error in a replication worker.Tom Lane2022-11-03
| | | | | | | | | | | | | | | | | | | | | | | If a syntax error occurred in a SQL-language or PL/pgSQL-language CREATE FUNCTION or DO command executed in a logical replication worker, we'd suffer a null pointer dereference or assertion failure. That seems like a rather contrived case, but nonetheless worth fixing. The cause is that function_parse_error_transpose assumes it must be executing within the context of a Portal, but logical/worker.c doesn't create a Portal since it's not running the standard executor. We can just back off the hard Assert check and make it fail gracefully if there's not an ActivePortal. (I have a feeling that the aggressive check here was my fault originally, probably because I wasn't sure if the case would always hold and wanted to find out. Well, now we know.) The hazard seems to exist in all branches that have logical replication, so back-patch to v10. Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane Discussion: https://postgr.es/m/b570c367-ba38-95f3-f62d-5f59b9808226@inbox.ru Discussion: https://postgr.es/m/adf0452f-8c6b-7def-d35e-ab516c80088e@inbox.ru
* Add casts to simplehash.h to silence C++ warnings.Tom Lane2022-11-03
| | | | | | | | | | | | | | | | Casting the result of palloc etc. to the intended type is more per project style anyway. (The fact that cpluspluscheck doesn't notice these problems is because it doesn't expand any macros, which seems like a troubling shortcoming. Don't have a good idea about improving that.) Back-patch to v13, which is as far as the patch applies cleanly; doesn't seem worth working harder. David Geier Discussion: https://postgr.es/m/aa5d88a3-71f4-3455-11cf-82de0372c941@gmail.com
* Allow use of __sync_lock_test_and_set for spinlocks on any machine.Tom Lane2022-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | If we have no special-case code in s_lock.h for the current platform, but the compiler has __sync_lock_test_and_set, use that instead of failing. It's unlikely that anybody's __sync_lock_test_and_set would be so awful as to be worse than our semaphore-based fallback, but if it is, they can (continue to) use --disable-spinlocks. This allows removal of the RISC-V special case installed by commit c32fcac56, which generated exactly the same code but only on that platform. Usefully, the RISC-V buildfarm animals should now test at least the int variant of this patch. I've manually tested both variants on ARM by dint of removing the ARM-specific stanza. We don't want to drop that, because it already has some special knowledge and is likely to grow more over time. Likewise, this is not meant to preclude installing special cases for other arches if that proves worthwhile. Per discussion of a request to install the same code for loongarch64. Like the previous patch, we might as well back-patch to supported branches. Discussion: https://postgr.es/m/761ac43d44b84d679ba803c2bd947cc0@HSMAILSVR04.hs.handsome.com.cn
* Defend against unsupported partition relkind in logical replication worker.Tom Lane2022-11-02
| | | | | | | | | | | | | | | | | | | | Since partitions can be foreign tables not only plain tables, but logical replication only supports plain tables, we'd better check the relkind of a partition after we find it. (There was some discussion of checking this when adding a partitioned table to a subscription; but that would be inadequate since the troublesome partition could be added later.) Without this, the situation leads to a segfault or assertion failure. In passing, add a separate variable for the target Relation of a cross-partition UPDATE; reusing partrel seemed mighty confusing and error-prone. Shi Yu and Tom Lane, per report from Ilya Gladyshev. Back-patch to v13 where logical replication into partitioned tables became a thing. Discussion: https://postgr.es/m/6b93e3748ba43298694f376ca8797279d7945e29.camel@gmail.com
* pg_dump: fix failure to dump comments on constraints in some cases.Tom Lane2022-11-02
| | | | | | | | | Thinko in commit 5209c0ba0: I checked the wrong object's DUMP_COMPONENT_COMMENT bit in two places. Per bug #17675 from Franz-Josef Färber. Discussion: https://postgr.es/m/17675-c69c001e06390867@postgresql.org
* Fix copy-and-pasteo in comment.Etsuro Fujita2022-11-02
|
* Fix outdated comment in tuplesort.hDavid Rowley2022-11-02
| | | | | | This was outdated by 77bae396d. Backpatch-through: 15, where 77bae396d was added
* Update time zone data files to tzdata release 2022f.Tom Lane2022-11-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DST law changes in Chile, Fiji, Iran, Jordan, Mexico, Palestine, and Syria. Historical corrections for Chile, Crimea, Iran, and Mexico. Also, the Europe/Kiev zone has been renamed to Europe/Kyiv (retaining the old name as a link). The following zones have been merged into nearby, more-populous zones whose clocks have agreed since 1970: Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis. (This indirectly affects zones that were already links to one of these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.) America/Nipigon, America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and Europe/Zaporozhye were also merged into nearby zones after discovering that their claimed post-1970 differences from those zones seem to have been errors. While the IANA crew have been working on merging zones that have no post-1970 differences for some time, this batch of changes affects some zones that are significantly more populous than those merged in the past, notably parts of Europe. The loss of pre-1970 timezone history for those zones may be troublesome for applications expecting consistency of timestamptz display. As an example, the stored value '1944-06-01 12:00 UTC' would previously display as '1944-06-01 13:00:00+01' if the Europe/Stockholm zone is selected, but now it will read out as '1944-06-01 14:00:00+02'. There exists a "packrat" option that will build the timezone data files with this old data preserved, but the problem is that it also resurrects a bunch of other, far less well-attested data; so much so that actually more zones' contents change from 2022a with that option than without it. I have chosen not to do that here, for that reason and because it appears that no major OS distributions are using the "packrat" option, so that doing so would cause Postgres' behavior to diverge significantly depending on whether it was built with --with-system-tzdata. However, for anyone for whom these changes pose significant problems, there is a solution: build a set of timezone files with the "packrat" option and use those with Postgres.
* Fix planner failure with extended statistics on partitioned tables.Tom Lane2022-11-01
| | | | | | | | | | Some cases would result in "cache lookup failed for statistics object", due to trying to fetch inherited statistics when only non-inherited ones are available or vice versa. Richard Guo and Justin Pryzby Discussion: https://postgr.es/m/20221030170520.GM16921@telsasoft.com
* Under has_wal_read_bug, skip recovery/t/032_relfilenode_reuse.pl.Noah Misch2022-10-29
| | | | | | | Per buildfarm member kittiwake. Back-patch to v15, where this test first appeared. Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com
* Fix ordering issue with WAL operations in GIN fast insert pathMichael Paquier2022-10-26
| | | | | | | | | | | | | | | | | | | | | | | | Contrary to what is documented in src/backend/access/transam/README, ginHeapTupleFastInsert() had a few ordering issues with the way it does its WAL operations when inserting items in its fast path. First, when using a separate list, XLogBeginInsert() was being always called before START_CRIT_SECTION(), and in this case a second thing was wrong when merging lists, as an exclusive lock was taken on the tail page *before* calling XLogBeginInsert(). Finally, when inserting items into a tail page, the order of XLogBeginInsert() and START_CRIT_SECTION() was reversed. This commit addresses all these issues by moving the calls of XLogBeginInsert() after all the pages logged are locked and pinned, within a critical section. This has been applied first only on HEAD as of 56b6625, but as per discussion with Tom Lane and Álvaro Herrera, a backpatch is preferred to keep all the branches consistent and to respect the transam's README where we can. Author: Matthias van de Meent, Zhang Mingli Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com Backpatch-through: 10
* Update some comments that should've covered MERGEAlvaro Herrera2022-10-24
| | | | | | | Oversight in 7103ebb7aae8. Backpatch to 15. Author: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/CAMbWs48gnDjZXq3-b56dVpQCNUJ5hD9kdtWN4QFwKCEapspNsA@mail.gmail.com
* psql: Fix exit status when query is canceledPeter Eisentraut2022-10-22
| | | | | | Because of a small thinko in 7844c9918a43b494adde3575891d217a37062378, psql -c would exit successfully when a query is canceled. Fix this so that it exits with a nonzero status, just like for all other errors.
* pg_basebackup: Fix cross-platform tablespace relocation.Robert Haas2022-10-21
| | | | | | | | | | | | | | Specifically, when pg_basebackup is invoked with -Tx=y, don't error out if x could plausibly be an absolute path either on Windows or on non-Windows systems. We don't know whether the remote system is running the same OS as the local system, so it's not appropriate to assume that our local rule about absolute pathnames is the same as the rule on the remote system. Patch by me, reviewed by Tom Lane, Andrew Dunstan, and Davinder Singh. Discussion: http://postgr.es/m/CA+TgmoY+jC3YiskomvYKDPK3FbrmsDU7_8+wMHt02HOdJeRb0g@mail.gmail.com
* Add CHECK_FOR_INTERRUPTS while restoring changes during decoding.Amit Kapila2022-10-21
| | | | | | | | | | | Previously in commit 42681dffaf, we added CFI during decoding changes but missed another similar case that can happen while restoring changes spilled to disk back into memory in a loop. Reported-by: Robert Haas Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CA+TgmoaLObg0QbstbC8ykDwOdD1bDkr4AbPpB=0DPgA2JW0mFg@mail.gmail.com
* Fix executing invalidation messages generated by subtransactions during ↵Amit Kapila2022-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decoding. This problem has been introduced by commit 272248a0c1 where we started assigning the subtransactions to the top-level transaction when we mark both the top-level transaction and its subtransactions as containing catalog changes. After we assign subtransactions to the top-level transaction, we were not allowed to execute any invalidations associated with it when we decide to skip the transaction. The reason to assign the subtransactions to the top-level transaction was to avoid the assertion failure in AssertTXNLsnOrder() as they have the same LSN when we sometimes start accumulating transaction changes for partial transactions after the restart. Now that with commit 64ff0fe4e8, we skip this assertion check until we reach the LSN at which we start decoding the contents of the transaction, so, there is no reason for such an assignment anymore. The assignment change was introduced in 15 and prior versions but this bug doesn't exist in branches prior to 14 since we don't add invalidation messages to subtransactions. We decided to backpatch through 11 for consistency but not for 10 since its final release is near. Reported-by: Kuroda Hayato Author: Masahiko Sawada Reviewed-by: Amit Kapila Backpatch-through: 11 Discussion: https://postgr.es/m/TYAPR01MB58660803BCAA7849C8584AA4F57E9%40TYAPR01MB5866.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com
* Fix assertion failures while processing NEW_CID record in logical decoding.Amit Kapila2022-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the logical decoding restarts from NEW_CID, since there is no association between the top transaction and its subtransaction, both are created as top transactions and have the same LSN. This caused the assertion failure in AssertTXNLsnOrder(). This patch skips the assertion check until we reach the LSN at which we start decoding the contents of the transaction, specifically start_decoding_at LSN in SnapBuild. This is okay because we don't guarantee to make the association between top transaction and subtransaction until we try to decode the actual contents of transaction. The ordering of the records prior to the start_decoding_at LSN should have been checked before the restart. The other assertion failure is due to the reason that we forgot to track that we have considered top-level transaction id in the list of catalog changing transactions that were committed when one of its subtransactions is marked as containing catalog change. Reported-by: Tomas Vondra, Osumi Takamichi Author: Masahiko Sawada, Kuroda Hayato Reviewed-by: Amit Kapila, Dilip Kumar, Kuroda Hayato, Kyotaro Horiguchi, Masahiko Sawada Backpatch-through: 10 Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com Discussion: https://postgr.es/m/TYCPR01MB83733C6CEAE47D0280814D5AED7A9%40TYCPR01MB8373.jpnprd01.prod.outlook.com
* Track LLVM 15 changes.Thomas Munro2022-10-19
| | | | | | | | | | | | Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque pointers still exists and we can request that on our context. We have until LLVM 16 to move to opaque pointers, a much larger change. Back-patch to 11, where LLVM support arrived. Author: Thomas Munro <thomas.munro@gmail.com> Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CAMHz58Sf_xncdyqsekoVsNeKcruKootLtVH6cYXVhhUR1oKPCg%40mail.gmail.com
* Rework shutdown callback of archiver modulesMichael Paquier2022-10-19
| | | | | | | | | | | | | | | | | | | | | | | As currently designed, with a callback registered in a ERROR_CLEANUP block, the shutdown callback would get called twice when updating archive_library on SIGHUP, which is something that we want to avoid to ease the life of extension writers. Anyway, an ERROR in the archiver process is treated as a FATAL, stopping it immediately, hence there is no need for a ERROR_CLEANUP block. Instead of that, the shutdown callback is not called upon before_shmem_exit(), giving to the modules the opportunity to do any cleanup actions before the server shuts down its subsystems. While on it, this commit adds some testing coverage for the shutdown callback. Neither shell_archive nor basic_archive have been using it, and one is added to shell_archive, whose trigger is checked in a TAP test through a shutdown sequence. Author: Nathan Bossart, Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/20221015221328.GB1821022@nathanxps13 Backpatch-through: 15
* Improve errhint for ALTER SUBSCRIPTION ADD/DROP PUBLICATIONAlvaro Herrera2022-10-18
| | | | | | | | | | | | | | | The original hint says to use SET PUBLICATION when really ADD/DROP PUBLICATION is called for, so this is arguably a bug fix. Also, a very similar message elsewhere was using an inconsistent SQLSTATE. While at it, unwrap some strings. Backpatch to 15. Author: Hou zj <houzj.fnst@fujitsu.com> Discussion: https://postgr.es/m/OS0PR01MB57160AD0E7386547BA978EB394299@OS0PR01MB5716.jpnprd01.prod.outlook.com
* Rename SetSingleFuncCall() to InitMaterializedSRF()Michael Paquier2022-10-18
| | | | | | | | | | | | | | | | | | Per discussion, the existing routine name able to initialize a SRF function with materialize mode is unpopular, so rename it. Equally, the flags of this function are renamed, as of: - SRF_SINGLE_USE_EXPECTED -> MAT_SRF_USE_EXPECTED_DESC - SRF_SINGLE_BLESS -> MAT_SRF_BLESS The previous function and flags introduced in 9e98583 are kept around for compatibility purposes, so as any extension code already compiled with v15 continues to work as-is. The declarations introduced here for compatibility will be removed from HEAD in a follow-up commit. The new names have been suggested by Andres Freund and Melanie Plageman. Discussion: https://postgr.es/m/20221013194820.ciktb2sbbpw7cljm@awork3.anarazel.de Backpatch-through: 15
* Reject non-ON-SELECT rules that are named "_RETURN".Tom Lane2022-10-17
| | | | | | | | | | | | DefineQueryRewrite() has long required that ON SELECT rules be named "_RETURN". But we overlooked the converse case: we should forbid non-ON-SELECT rules that are named "_RETURN". In particular this prevents using CREATE OR REPLACE RULE to overwrite a view's _RETURN rule with some other kind of rule, thereby breaking the view. Per bug #17646 from Kui Liu. Back-patch to all supported branches. Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org
* Guard against table-AM-less relations in planner.Tom Lane2022-10-17
| | | | | | | | | | | | | | | The executor will dump core if it's asked to execute a seqscan on a relation having no table AM, such as a view. While that shouldn't really happen, it's possible to get there via catalog corruption, such as a missing ON SELECT rule. It seems worth installing a defense against that. There are multiple plausible places for such a defense, but I picked the planner's get_relation_info(). Per discussion of bug #17646 from Kui Liu. Back-patch to v12 where the tableam APIs were introduced; in older versions you won't get a SIGSEGV, so it seems less pressing. Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org
* Fix EXPLAIN of SEARCH BREADTH FIRST with a constant initial value.Tom Lane2022-10-16
| | | | | | | | | | | | | | | | | | | | | | If the non-recursive term of a SEARCH BREADTH FIRST recursive query has only constants in its target list, the planner will fold the starting RowExpr added by rewrite into a simple Const of type RECORD. The executor doesn't have any problem with that --- but EXPLAIN VERBOSE will encounter the Const as the ultimate source of truth about what the field names of the SET column are, and it didn't know what to do with that. Fortunately, we can pull the identifying typmod out of the Const, in much the same way that record_out would. For reasons that remain a bit obscure to me, this only fails with SEARCH BREADTH FIRST, not SEARCH DEPTH FIRST or CYCLE. But I added regression test cases for both of those options too, just to make sure we don't break it in future. Per bug #17644 from Matthijs van der Vleuten. Back-patch to v14 where these constructs were added. Discussion: https://postgr.es/m/17644-3bd1f3036d6d7a16@postgresql.org
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 00:10:51 +0000