aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* 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
* Doc: improve tutorial section about grouped aggregates.Tom Lane2022-11-08
| | | | | | | | | | | | | | | | | | | | | Commit fede15417 introduced FILTER by jamming it into the existing example introducing HAVING, which seems pedagogically poor to me; and it added no information about what the keyword actually does. Not to mention that the claimed output didn't match the sample data being used in this running example. Revert that and instead make an independent example using FILTER. To help drive home the point that it's a per-aggregate filter, we need to use two aggregates not just one; for consistency expand all the examples in this segment to do that. Also adjust the example using WHERE ... LIKE so that it'd produce nonempty output with this sample data, and show that output. Back-patch, as the previous patch was. (Sadly, v10 is now out of scope.) Discussion: https://postgr.es/m/166794307526.652.9073408178177444190@wrigleys.postgresql.org
* Stamp 15.1.REL_15_1Tom Lane2022-11-07
|
* Translation updatesAlvaro Herrera2022-11-07
| | | | | Source-Git-URL: ssh://git@git.postgresql.org/pgtranslation/messages.git Source-Git-Hash: 0a578288026cfaae6b3d120b3ecf719aaa94dfdc
* Last-minute updates for release notes.Tom Lane2022-11-07
|
* 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
* Release notes for 15.1, 14.6, 13.9, 12.13, 11.18, 10.23.Tom Lane2022-11-06
|
* First-draft release notes for 15.1.Tom Lane2022-11-04
| | | | | | | | | As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. Also as usual for a .1 release, there are some entries here that are not really relevant for v15 because they already appeared in 15.0. Those'll be removed later.
* 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
* docs: Improve pg_settings_get_flags docs.Tom Lane2022-11-03
| | | | | | | | | | | | | | | | In the docs, the GUC flags that pg_settings_get_flags() reported were listed using <simplelist>. But the list was treated as separate lines in the existing function table and didn't look good. For better view, this commit separates the list from the table entry for pg_settings_get_flags() and adds the table for it at the bottom of the existing function table. Author: Fujii Masao Reviewed-by: Alvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/f093edf9-6e5a-b119-ee50-6a2c97c79ee8@oss.nttdata.com Back-patch of f2d0c7f18 into v15. Discussion: https://postgr.es/m/20221103123320.GQ16921@telsasoft.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
|
* doc: Fix some descriptions related to pg_ident_file_mappingsMichael Paquier2022-11-02
| | | | | | | | | | | | | | pg_ident_file_mappings.line_number was described as a line number in pg_ident.conf for a "rule" number, but this should refer to a "map". The same inconsistent term was used in the main paragraph describing the view. Extracted from a patch by the same author. Issue introduced by a2c8499 where this view has been added. Author: Julien Rouhaud Discussion: https://postgr.es/m/20221026031948.cbrnzgy5e7glsq2d@jrouhaud Backpatch-through: 15
* 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
* pg_stat_statements: fetch stmt location/length before it disappears.Tom Lane2022-11-01
| | | | | | | | | | | | | | | | | | | | When executing a utility statement, we must fetch everything we need out of the PlannedStmt data structure before calling standard_ProcessUtility. In certain cases (possibly only ROLLBACK in extended query protocol), that data structure will get freed during command execution. The situation is probably often harmless in production builds, but in debug builds we intentionally overwrite the freed memory with garbage, leading to picking up garbage values of statement location and length, typically causing an assertion failure later in pg_stat_statements. In non-debug builds, if something did go wrong it would likely lead to storing garbage for the query string. Report and fix by zhaoqigui (with cosmetic adjustments by me). It's an old problem, so back-patch to all supported versions. Discussion: https://postgr.es/m/17663-a344fd0675f92128@postgresql.org Discussion: https://postgr.es/m/1667307420050.56657@hundsun.com
* Remove incorrect name from release notesPeter Eisentraut2022-11-01
| | | | | | | This name was incorrect in the underlying commit message. (The correct name is already listed.) Reported-by: Mark Wong
* 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
* doc: Fix type of cursor_position in jsonlog tableMichael Paquier2022-10-25
| | | | | | | | | | This entry was listed as a "string", but it is a "number. The other fields are correctly described, on a second look. Reported-by: Nuko Yokohama Author: Tatsuo Ishii Discussion: https://postgr.es/m/CAF3Gu1awoVoDP5d0_eN=cR=QkGVwH+OtFvwJkkc5cB_ZMWjyeA@mail.gmail.com Backpatch-through: 15
* 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
* Doc: fix outdated wording about parallel seq scansDavid Rowley2022-10-21
| | | | | | | | | | | | | 56788d215 adjusted the parallel seq scan code so that instead of handing out a single block at a time to parallel workers, it now hands out ranges of blocks. Here we update the documentation which still claimed that workers received just 1 block at a time. Reported-by: Zhang Mingli Discussion: https://postgr.es/m/17c99615-2c3b-4e4e-9d0b-424a66a7bccd@Spark Backpatch-through: 14, where 56788d215 was added.
* 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
* doc: move the mention of aggregate JSON functions up in sectionBruce Momjian2022-10-17
| | | | | | | | | | It was previously easily overlooked at the end of several tables. Reported-by: Alex Denman Discussion: https://postgr.es/m/166335888474.659.16897487975376230364@wrigleys.postgresql.org Backpatch-through: 10
* doc: warn pg_stat_reset() can cause vacuum/analyze problemsBruce Momjian2022-10-17
| | | | | | | | | | The fix is to run ANALYZE. Discussion: https://postgr.es/m/YzRr+ys98UzVQJvK@momjian.us, https://postgr.es/m/flat/CAKJS1f8DTbCHf9gedU0He6ARsd58E6qOhEHM1caomqj_r9MOiQ%40mail.gmail.com, https://postgr.es/m/CAKJS1f80o98hcfSk8j%3DfdN09S7Sjz%2BvuzhEwbyQqvHJb_sZw0g%40mail.gmail.com Backpatch-through: 10
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-02 10:28:27 +0000