aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* doc: Add index entry for MERGE SQL command.Fujii Masao2022-07-01
| | | | | | | | Back-patch to v15, where MERGE command was supported. Author: Fujii Masao Reviewed-by: Alvaro Herrera Discussion: https://postgr.es/m/4e7a4b38-c34a-ce2c-c71e-832d2b768b29@oss.nttdata.com
* Clarify that pg_dump takes ACCESS SHARE lockJohn Naylor2022-07-01
| | | | | | | | | | Add link to the description of lock levels to avoid confusing "shared locks" with SHARE locks. Florin Irion Reviewed-by: Álvaro Herrera, Tom Lane, and Nathan Bossart Discussion: https://www.postgresql.org/message-id/flat/d0f30cc2-3c76-1d43-f291-7c4b2872d653@gmail.com
* Harden dsm_impl.c against unexpected EEXIST.Thomas Munro2022-07-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we trusted the OS not to report EEXIST unless we'd passed in IPC_CREAT | IPC_EXCL or O_CREAT | O_EXCL, as appropriate. Solaris's shm_open() can in fact do that, causing us to crash because we didn't ereport and then we blithely assumed the mapping was successful. Let's treat EEXIST just like any other error, unless we're actually trying to create a new segment. This applies to shm_open(), where this behavior has been seen, and also to the equivalent operations for our sysv and mmap modes just on principle. Based on the underlying reason for the error, namely contention on a lock file managed by Solaris librt for each distinct name, this problem is only likely to happen on 15 and later, because the new shared memory stats system produces shm_open() calls for the same path from potentially large numbers of backends concurrently during authentication. Earlier releases only shared memory segments between a small number of parallel workers under one Gather node. You could probably hit it if you tried hard enough though, and we should have been more defensive in the first place. Therefore, back-patch to all supported releases. Per build farm animal margay. This isn't the end of the story, though, it just changes random crashes into random "File exists" errors; more work needed for a green build farm. Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CA%2BhUKGKqKrCV5xKWfh9rnm%3Do%3DDwZLTLtnsj_XpUi9g5%3DV%2B9oyg%40mail.gmail.com
* Fix code comments still referring to pg_start/stop_backup()Michael Paquier2022-07-01
| | | | | | | | | pg_start_backup() and pg_stop_backup() have been respectively renamed to pg_backup_start() and pg_backup_stop() as of 39969e2, but a few comments did not get the call. Reviewed-by: Kyotaro Horiguchi, David Steele Discussion: https://postgr.es/m/YrqGlj1+4DF3dbZ/@paquier.xyz
* Refactor the TAP test of auto_explainMichael Paquier2022-07-01
| | | | | | | | | | | | | | | | | | Previously, the tests were structured so as all the queries whose plans are checked run first, followed by pattern checks using the full set of server logs. This can be problematic when extending the tests, as this increases query plan overlaps, where two tests finish by having similar plan outputs potentially invalidating the tests wanted. The tests are refactored so as log content matches are checked in isolation of each query run, by grabbing the position of the server logs before running each query whose plan is generated in the logs. This avoids issues when extending the tests, something that would become a larger problem with a follow-up patch that adds a new GUC in auto_explain to control the size of the each parameter logged. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87ee09mohb.fsf@wibble.ilmari.org
* Change some unnecessary MemSet callsPeter Eisentraut2022-07-01
| | | | | | | | | | MemSet() with a value other than 0 just falls back to memset(), so the indirection is unnecessary if the value is constant and not 0. Since there is some interest in getting rid of MemSet(), this gets some easy cases out of the way. (There are a few MemSet() calls that I didn't change to maintain the consistency with their surrounding code.) Discussion: https://www.postgresql.org/message-id/flat/CAEudQApCeq4JjW1BdnwU=m=-DvG5WyUik0Yfn3p6UNphiHjj+w@mail.gmail.com
* Avoid unnecessary MemSet callPeter Eisentraut2022-06-30
| | | | | | | | | | The variable in question was changed from a struct to a pointer some time ago (77947c51c08). Using MemSet to zero it still works but is obviously unidiomatic and confusing, so change it to a straight assignment. Author: Ranier Vilela <ranier.vf@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAEudQApCeq4JjW1BdnwU=m=-DvG5WyUik0Yfn3p6UNphiHjj+w@mail.gmail.com
* Stamp HEAD as 16devel.Tom Lane2022-06-30
| | | | Let the hacking begin ...
* Add 82d0ffae3 to git-blame-ignore-revs.Tom Lane2022-06-30
|
* pgindent run prior to branching v15.Tom Lane2022-06-30
| | | | pgperltidy and reformat-dat-files too. Not many changes.
* relnotes: update item about public schema permission changeBruce Momjian2022-06-28
| | | | | | | | Also mention the bootstrap superuser. Reported-by: Noah Misch Discussion: https://postgr.es/m/20220628063719.GA2208244@rfd.leadboat.com
* Stamp 15beta2.REL_15_BETA2Tom Lane2022-06-27
|
* Remove outdated recommendation for manual VACUUMMagnus Hagander2022-06-27
| | | | | | | | | | | | | | | | We have had a working and tunable autovacuum for at least a decade now, so remove the recommendation to manually vacuum tables at least every night. Autovacuum is now also triggered by INSERTs, so we can also remove the recommendation to run VACUUM (ANALYZE) after lots of INSERTs or DELETEs. Instead, suggest using autovacuum by moving the respective paragraph up to where the importance of VACUUM is emphasized. Author: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-By: Magnus Hagander, Peter Geoghegan Discussion: https://postgr.es/m/6f5e3da98fec14640f389d7b84c3b413833697f4.camel@cybertec.at
* PL/Python: Update guide to alternative expected filesPeter Eisentraut2022-06-27
| | | | | | | plpython_unicode_3.out was already removed a long time ago, so it being listed here was very out of date. plpython_types_3.out was removed with the Python 2 removal.
* pg_upgrade: Fix version comparison for global ICU supportPeter Eisentraut2022-06-27
| | | | | Reported-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://www.postgresql.org/message-id/20220625151930.GH22452@telsasoft.com
* doc: Mention attribute "inherited" in pg_stats_ext[_exprs]Michael Paquier2022-06-27
| | | | | | | | | These have been added in 269b532, but the documentation did not reflect that. Author: Noriyoshi Shinoda Reviewed-by: Justin Pryzby Discussion: https://postgr.es/m/DM4PR84MB17349C4E7D88A68264C18AF3EED69@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* Translation updatesPeter Eisentraut2022-06-27
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 46c120873f1e906cc8dab74d8d756417e1b367f6
* Fix visibility check when XID is committed in CLOG but not in procarray.Heikki Linnakangas2022-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TransactionIdIsInProgress had a fast path to return 'false' if the single-item CLOG cache said that the transaction was known to be committed. However, that was wrong, because a transaction is first marked as committed in the CLOG but doesn't become visible to others until it has removed its XID from the proc array. That could lead to an error: ERROR: t_xmin is uncommitted in tuple to be updated or for an UPDATE to go ahead without blocking, before the previous UPDATE on the same row was made visible. The window is usually very short, but synchronous replication makes it much wider, because the wait for synchronous replica happens in that window. Another thing that makes it hard to hit is that it's hard to get such a commit-in-progress transaction into the single item CLOG cache. Normally, if you call TransactionIdIsInProgress on such a transaction, it determines that the XID is in progress without checking the CLOG and without populating the cache. One way to prime the cache is to explicitly call pg_xact_status() on the XID. Another way is to use a lot of subtransactions, so that the subxid cache in the proc array is overflown, making TransactionIdIsInProgress rely on pg_subtrans and CLOG checks. This has been broken ever since it was introduced in 2008, but the race condition is very hard to hit, especially without synchronous replication. There were a couple of reports of the error starting from summer 2021, but no one was able to find the root cause then. TransactionIdIsKnownCompleted() is now unused. In 'master', remove it, but I left it in place in backbranches in case it's used by extensions. Also change pg_xact_status() to check TransactionIdIsInProgress(). Previously, it only checked the CLOG, and returned "committed" before the transaction was actually made visible to other queries. Note that this also means that you cannot use pg_xact_status() to reproduce the bug anymore, even if the code wasn't fixed. Report and analysis by Konstantin Knizhnik. Patch by Simon Riggs, with the pg_xact_status() change added by me. Author: Simon Riggs Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/flat/4da7913d-398c-e2ad-d777-f752cf7f0bbb%40garret.ru
* Fix relptr's encoding of the base address.Thomas Munro2022-06-27
| | | | | | | | | | | | | | | | | Previously, we encoded both NULL and the first byte at the base address as 0. That confusion led to the assertion in commit e07d4ddc, which failed when min_dynamic_shared_memory was used. Give them distinct encodings, by switching to 1-based offsets for non-NULL pointers. Also improve macro hygiene in passing (missing/misplaced parentheses), and remove open-coded access to the raw offset value from freepage.c/h. Although e07d4ddc was back-patched to 10, the only code that actually makes use of relptr at the base address arrived in 84b1c63a, so no need to back-patch further than 14 for now. Reported-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/20220519193839.GT19626%40telsasoft.com
* Harden range_table_mutator() against null RangeTblEntry.subquery.Tom Lane2022-06-26
| | | | | | | | | | | | | | | | | | | | Commit 64919aaab made pull_up_simple_subquery set rte->subquery = NULL after doing the deed, so that we don't waste cycles copying a now-useless subquery tree around. This turns out to create a core dump hazard in range_table_mutator, which supposes that that field is never NULL. Apparently none of our own code invokes query_tree_mutator or range_table_mutator on the top Query after subquery pullup; but it wouldn't be surprising if outside code does, and anyway I'm working on a v16 patch that will need it. We can fix this cleanly by just getting rid of the special-case handling of this field and treating it more like all the rest. I think the special case might be left over from a time when QTW_DONT_COPY_QUERY was the default behavior, but that was eons ago. Thanks to Dean Rasheed for review. Discussion: https://postgr.es/m/545569.1656107045@sss.pgh.pa.us
* Don't trust signalfd() on illumos.Thomas Munro2022-06-26
| | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 6a2a70a02, we've used signalfd() to receive latch wakeups when building with WAIT_USE_EPOLL (default for Linux and illumos), and our traditional self-pipe when falling back to WAIT_USE_POLL (default for other Unixes with neither epoll() nor kqueue()). Unexplained hangs and kernel panics have been reported on illumos systems, apparently linked to this use of signalfd(), leading illumos users and build farm members to have to define WAIT_USE_POLL explicitly as a work-around. A bug report exists at https://www.illumos.org/issues/13700 but no fix is available yet. Let's provide a way for illumos users to go back to self-pipes with epoll(), like releases before 14, and choose that by default. No change for Linux users. To help with development/debugging, macros WAIT_USE_{EPOLL,POLL} and WAIT_USE_{SIGNALFD,SELF_PIPE} can be defined explicitly to override the defaults. Back-patch to 14, where we started using signalfd(). Reported-by: Japin Li <japinli@hotmail.com> Reported-by: Olaf Bohlen <olbohlen@eenfach.de> (off-list) Reviewed-by: Japin Li <japinli@hotmail.com> Discussion: https://postgr.es/m/MEYP282MB1669C8D88F0997354C2313C1B6CA9%40MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
* CREATE INDEX: use the original userid for more ACL checks.Noah Misch2022-06-25
| | | | | | | | | | | | | Commit a117cebd638dd02e5c2e791c25e43745f233111b used the original userid for ACL checks located directly in DefineIndex(), but it still adopted the table owner userid for more ACL checks than intended. That broke dump/reload of indexes that refer to an operator class, collation, or exclusion operator in a schema other than "public" or "pg_catalog". Back-patch to v10 (all supported versions), like the earlier commit. Nathan Bossart and Noah Misch Discussion: https://postgr.es/m/f8a4105f076544c180a87ef0c4822352@stmuk.bayern.de
* Use --no-unlogged-table-data in t/027_stream_regress.pl.Noah Misch2022-06-25
| | | | | | | | | This removes the need to drop unlogged relations in the src/test/regress suite, like commit dec8ad367e46180f826d5b6dc820fbecba1b71d2 did. Reviewed by Thomas Munro. Discussion: https://postgr.es/m/39945.1650895508@sss.pgh.pa.us
* Remove unportable testPeter Eisentraut2022-06-24
| | | | | | | | | | | | | | | | The ssl test "IPv4 host with CIDR mask does not match" apparently has a portability problem. Some operating systems don't reject the host name specification "192.0.2.1/32" as an IP address, and that is then later rejected when the SNI is set, which results in a different error message that the test is supposed to verify. The value of the test has been questioned in the discussion, and it was suggested that removing it would be an acceptable fix, so that's what this is doing. Reported-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Bug: #17522 Discussion: https://www.postgresql.org/message-id/flat/17522-bfcd5c603b5f4daa%40postgresql.org
* Fix intermetent test failure in 028_row_filter.pl.Amit Kapila2022-06-24
| | | | | | | | | | | | The test was not waiting for the subscriber's data synchronization to happen after refreshing the publication on the subscriber side. This leads subscriber's apply worker to skip applying the changes on the corresponding relation which results in a test failure. Reported-by: Hou Zhijie, as per buildfarm Author: Hou Zhijie Reviewed-by: Masahiko Sawada, Amit Kapila Discussion: https://postgr.es/m/OS0PR01MB5716A69496A8E2F2E155DB8D94B59@OS0PR01MB5716.jpnprd01.prod.outlook.com
* Doc: clarify that tablesync ignores publish operation.Amit Kapila2022-06-24
| | | | | | | | | | This patch documents that the initial data synchronization (tablesync) for logical replication does not take into account the publication 'publish' parameter when copying the existing table data. Author: Peter Smith Reviewed-by: Shi yu, Euler Taveira, Robert Haas, Amit Kapila Discussion: https://postgr.es/m/CAHut+PtbfALjFpS2MkrvQ+wWQKByP7CNh9RtFta-r=BHEU3S3w@mail.gmail.com
* Fix missing newline at end of messagePeter Eisentraut2022-06-23
|
* Fix typo in pg_publication.cMichael Paquier2022-06-23
| | | | | Author: Peter Smith Discussion: https://postgr.es/m/CAHut+PuV2XXjC4spHXy_EOhpD6MDrmmDMWnVJLYpd1_P=2+mJw@mail.gmail.com
* PL/Tcl: Don't link with -lc explicitlyPeter Eisentraut2022-06-23
| | | | | | | | | | | | | | | | | | It has been reported that PL/Tcl built on macOS with GCC >=11 crashes. The reason is that there is a hash_search() function in the operating system's libraries, and that ends up being called instead of the one in postgres. This has something to do with how the linker resolves references between the various possibilities it has been given, and somehow something changed that it is now picking that one in this configuration. We found that removing the -lc from the link command line fixes this problem. The -lc was introduced a long time ago in commit e3909672f12e0ddf3e202b824fda068ad2195ef2, and we think the reasons might be obsolete, so we decided that we'll try to just remove it and see if any problems arise. Discussion: https://www.postgresql.org/message-id/flat/a78c847a-4f79-9286-be99-e819e9e4139e%40enterprisedb.com
* Fix memory leak due to LogicalRepRelMapEntry.attrmap.Amit Kapila2022-06-23
| | | | | | | | | | | | | | When rebuilding the relation mapping on subscribers, we were not releasing the attribute mapping's memory which was no longer required. The attribute mapping used in logical tuple conversion was refactored in PG13 (by commit e1551f96e6) but we forgot to update the related code that frees the attribute map. Author: Hou Zhijie Reviewed-by: Amit Langote, Amit Kapila, Shi yu Backpatch-through: 10, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
* Fix two issues with HEADER MATCH in COPYMichael Paquier2022-06-23
| | | | | | | | | | | | | | | | | | | | 072132f0 used the attnum offset to access the raw_fields array when checking that the attribute names of the header and of the relation match, leading to incorrect results or even crashes if the attribute numbers of a relation are changed, like on a dropped attribute. This fixes the logic to use the correct attribute names for the header matching requirements. Also, this commit disallows HEADER MATCH in COPY TO as there is no validation that can be done in this case. The tests are expanded for HEADER MATCH with COPY FROM and dropped columns, with cases where a relation has a dropped and re-added column, as well as a reduced set of columns. Author: Julien Rouhaud Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/20220607154744.vvmitnqhyxrne5ms@jrouhaud
* pgstat: Mention pgstat_replslot.c in pgstat.c.Andres Freund2022-06-22
| | | | | | | Oversight, by me, in commit 5891c7a8ed8. Author: "Drouvot, Bertrand" <bdrouvot@amazon.com> Discussion: https://postgr.es/m/bd58e027-6598-57a2-679b-d576d17bfaa9@amazon.com
* doc: improve wording of plpgsql RAISE format textBruce Momjian2022-06-22
| | | | | | | | Reported-by: pg@kirasoft.com Discussion: https://postgr.es/m/165455351426.573551.7050474465030525109@wrigleys.postgresql.org Backpatch-through: 10
* doc: clarify wording about phantom readsBruce Momjian2022-06-22
| | | | | | | | Reported-by: akhilhello@gmail.com Discussion: https://postgr.es/m/165222922369.669.10475917322916060899@wrigleys.postgresql.org Backpatch-through: 10
* amcheck: Fix incorrect use of VARATT_IS_COMPRESSED.Robert Haas2022-06-22
| | | | | | | | | | | The macro is being applied to a TOAST pointer, not a varlena header. Therefore the use of VARATT_IS_COMPRESSED() is wrong. We can check VARATT_EXTERNAL_IS_COMPRESSED(), but then we don't need the length check that follows. Report and fix by Kyotaro Horiguchi. Discussion: http://postgr.es/m/20220517.162719.1671558681467343711.horikyota.ntt@gmail.com
* doc: Clean up title case usePeter Eisentraut2022-06-22
|
* Simplify tab completion of extension versions.Tom Lane2022-06-21
| | | | | | | | | | | | | | | | Second thoughts about 9cd43f6cb: given that we're staying bug-compatible with the old behavior of using double not single quotes for extension versions, we can simplify this completion code by pretending that extension versions *are* identifiers, and not using VERBATIM. Then _complete_from_query() will think that the query results are identifiers in need of quoting, and we end up with the same behavior as before. This doesn't work for Query_for_list_of_available_extension_versions_with_TO, but let's just drop that: there is no other place where we handle multi-keyword phrases that way, and it doesn't seem very desirable here either. Handle completion of "UPDATE TO" in our more usual pattern. Discussion: https://postgr.es/m/CAMkU=1yV+egSYrzWvbDY8VZ6bKEMrKbzxr-HTuiHi+wDgSUMgA@mail.gmail.com
* Fix stale values in partition map entries on subscribers.Amit Kapila2022-06-21
| | | | | | | | | | | | | | | | | | We build the partition map entries on subscribers while applying the changes for update/delete on partitions. The component relation in each entry is closed after its use so we need to update it on successive use of cache entries. This problem was there since the original commit f1ac27bfda that introduced this code but we didn't notice it till the recent commit 26b3455afa started to use the component relation of partition map cache entry. Reported-by: Tom Lane, as per buildfarm Author: Amit Langote, Hou Zhijie Reviewed-by: Amit Kapila, Shi Yu Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
* doc: Make some synopsis punctuation consistentPeter Eisentraut2022-06-21
|
* Fix partition table's REPLICA IDENTITY checking on the subscriber.Amit Kapila2022-06-21
| | | | | | | | | | | | | | | | | | | | In logical replication, we will check if the target table on the subscriber is updatable by comparing the replica identity of the table on the publisher with the table on the subscriber. When the target table is a partitioned table, we only check its replica identity but not for the partition tables. This leads to assertion failure while applying changes for update/delete as we expect those to succeed only when the corresponding partition table has a primary key or has a replica identity defined. Fix it by checking the replica identity of the partition table while applying changes. Reported-by: Shi Yu Author: Shi Yu, Hou Zhijie Reviewed-by: Amit Langote, Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
* Fix file references inside some SGML commentsPeter Eisentraut2022-06-20
| | | | | | | | In some cases, the comments mentioning their own file or another file were not correct. Author: Josh Soref <jsoref@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CACZqfqCyhE-voJUrUkc3GQuDakfJKx1ViiCdY7B8tQwyL6727g%40mail.gmail.com
* relnotes: simplify wording of pg_basebackup compression itemBruce Momjian2022-06-19
|
* Message and documentation refinementsPeter Eisentraut2022-06-19
|
* Fix busted tab completion of extension versions.Tom Lane2022-06-18
| | | | | | | | | | | | | | | | | | | In 02b8048ba I (tgl) got rid of the need for most tab-completion queries to return pre-quoted identifiers. But I over-hastily removed the quote_ident call from Query_for_list_of_available_extension_versions* too; those still need it, because what is returned isn't an identifier at all and will (almost?) always need quoting. Arguably we should use quote_literal here instead. But quote_ident works too and people may be used to that behavior, so stick with it. In passing, fix inconsistent omission of schema-qualification in Query_for_list_of_encodings. That's not a security issue per our current guidelines, but it ought to be like the rest. Jeff Janes Discussion: https://postgr.es/m/CAMkU=1yV+egSYrzWvbDY8VZ6bKEMrKbzxr-HTuiHi+wDgSUMgA@mail.gmail.com
* doc: Do s/int/integer/ to describe the type of some GUC parametersMichael Paquier2022-06-17
| | | | | | | | | | | | | | Three parameters have been using "int" rather than "integer" to describe their type: auth_delay.milliseconds max_logical_replication_workers pg_prewarm.autoprewarm_interval This is inconsistent with any other integer GUCs listed in the docs (148, as far as I can see). Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv6X5T-veN2abUDUvBxZm+SSm-9otfi3LZPGyOc6u6hiA@mail.gmail.com
* Revert changes in HOT handling of BRIN indexesTomas Vondra2022-06-16
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commits 5753d4ee32 and fe60b67250 that modified HOT to ignore BRIN indexes. The commit message for 5753d4ee32 claims that: When determining whether an index update may be skipped by using HOT, we can ignore attributes indexed only by BRIN indexes. There are no index pointers to individual tuples in BRIN, and the page range summary will be updated anyway as it relies on visibility info. This is partially incorrect - it's true BRIN indexes don't point to individual tuples, so HOT chains are not an issue, but the visibitlity info is not sufficient to keep the index up to date. This can easily result in corrupted indexes, as demonstrated in the hackers thread. This does not mean relaxing the HOT restrictions for BRIN is a lost cause, but it needs to handle the two aspects (allowing HOT chains and updating the page range summaries) as separate. But that requires a major changes, and it's too late for that in the current dev cycle. Reported-by: Tomas Vondra Discussion: https://postgr.es/m/05ebcb44-f383-86e3-4f31-0a97a55634cf@enterprisedb.com
* Fix comment in regression tests for large objectsMichael Paquier2022-06-16
| | | | | | | | | The values assigned to INV_WRITE and INV_READ were reversed in the tests, which would be confusing when writing tests specific to read or write operations on LOs. Author: Yugo Nagata Discussion: https://postgr.es/m/20220527153028.61a4608f66abcd026fd3806f@sraoss.co.jp
* Fix data inconsistency between publisher and subscriber.Amit Kapila2022-06-16
| | | | | | | | | | | | | | | | We were not updating the partition map cache in the subscriber even when the corresponding remote rel is changed. Due to this data was getting incorrectly replicated for partition tables after the publisher has changed the table schema. Fix it by resetting the required entries in the partition map cache after receiving a new relation mapping from the publisher. Reported-by: Shi Yu Author: Shi Yu, Hou Zhijie Reviewed-by: Amit Langote, Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
* Link to MVCC docs in MERGE docsAlvaro Herrera2022-06-15
| | | | | | | | | | In addition, this moves the new paragraph in the MVCC page upwards, for a more consistent flow; some minor markup mistakes, style issues and typos are fixed too. Per comments from Justin Pryzby. Discussion: https://postgr.es/m/20220511163350.GL19626@telsasoft.com
* Re-add locally-generated files in pg_upgrade's .gitignore and MakefileMichael Paquier2022-06-15
| | | | | | | | | | | | | | | | | This reverts the changes to pg_upgrade's Makefile and .gitignore done in 15b6d21. The TAP tests run in isolation, executing pg_upgrade in tmp_check/ in the build directory so as any files created in the execution path (reindex_hash.sql and delete_old_cluster.{sh,bat}) are never in the tree, so entries are not necessary in this case. However, not having these impacts the cleanliness of the code tree when running ./pg_upgrade directly from src/bin/pg_upgrade/. This commit adds back to .gitignore all the files generated in the execution path, and the Makefile rule to clean them up if they exist. Per gripe from Tom Lane. Discussion: https://postgr.es/m/90595.1655227384@sss.pgh.pa.us
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 11:39:47 +0000