pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/da99df15c25d9c769f24a721f34ed062d0b5d4d2 Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9ee1339bfbe078ee04468dfce2820248061155b Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0d5a3d7574f8dabcbc229c2a06a9cb2d9a43c7c5 Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/db1992455569265be12efc65720cfe13ca64122c Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4c922821e12e5a7526dac9049a4c8af861375103 Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/159bf0f31b59f7ef7f4bc6c3f57a5187f6a96947 Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove NULL dereference from RenameRelationInternal().
Remove NULL dereference from RenameRelationInternal(). Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b, per Coverity. Reaching this would need catalog corruption. Back-patch to v12, like that commit. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5a33a39a8bb4540e760110202853aded611b1e7c Modified Files -- src/backend/commands/tablecmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/91e5add02ba98ab3d46db6d3b457d6fd084f1ae3 Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7f90b727422bde6308fd22b7fb0aef48255fd6db Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4aad471688993d3f6cfb8afa8b3af52b2fbdc7a3 Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0c827fbdb81ad873921c3fae4d973151d8a00785 Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c1ff2d8bc5be55e302731a16aaff563b7f03ed7c Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a709c456fc97b6d5452fe2117afc9a4c3b09da9 Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Avoid 037_invalid_database.pl hang under debug_discard_caches.
Avoid 037_invalid_database.pl hang under debug_discard_caches. Back-patch to v12 (all supported versions). Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/118dfd12138fe1eb57c0720d1d67bd17500eca31 Modified Files -- src/test/recovery/t/037_invalid_database.pl | 25 + 1 file changed, 17 insertions(+), 8 deletions(-)
pgsql: Fix use of uninitialized value in previous commit.
Fix use of uninitialized value in previous commit. Per buildfarm member akepa and others. Back-patch to v16 and v15. Discussion: https://postgr.es/m/20240924224352.93.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/90f5412a9a513f2d8e4fee1102946219482b8af1 Modified Files -- src/backend/executor/nodeModifyTable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix use of uninitialized value in previous commit.
Fix use of uninitialized value in previous commit. Per buildfarm member akepa and others. Back-patch to v16 and v15. Discussion: https://postgr.es/m/20240924224352.93.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0cf3d41cbb425c142ca7b3f1e2efd875565b6142 Modified Files -- src/backend/executor/nodeModifyTable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8590c942c1a6b861d0cf4fa5aa694ab3a65fa306 Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 252 +++-- src/backend/access/index/genam.c | 137 +++ src/backend/catalog/index.c| 38 +--- src/backend/catalog/toasting.c | 31 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 7 + .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- 13 files changed, 486 insertions(+), 96 deletions(-)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7354b680ab64fbde6072f248fe3b2ff909a99d12 Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 248 +++-- src/backend/access/index/genam.c | 138 src/backend/catalog/index.c| 38 +--- src/backend/catalog/toasting.c | 31 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 7 + .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- 13 files changed, 485 insertions(+), 94 deletions(-)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a8ad1929d2ec04a5e46dd51d2ef5768c7179ef0b Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 248 +++-- src/backend/access/index/genam.c | 138 src/backend/catalog/index.c| 38 +--- src/backend/catalog/toasting.c | 31 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 7 + .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- 13 files changed, 485 insertions(+), 94 deletions(-)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/63f01980560adb57524f8b004b8f47de7e29cc38 Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 252 +++-- src/backend/access/index/genam.c | 136 +++ src/backend/catalog/index.c| 38 +--- src/backend/catalog/toasting.c | 31 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 7 + .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- 13 files changed, 485 insertions(+), 96 deletions(-)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aac2c9b4fde889d13f859c233c2523345e72d32b Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 25 +++- src/backend/commands/event_trigger.c | 7 +- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execMain.c| 6 + src/backend/executor/execReplication.c | 6 +- src/backend/executor/nodeModifyTable.c | 98 +++--- src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/nodes/execnodes.h | 3 + src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 20 files changed, 498 insertions(+), 57 deletions(-)
pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta
Back-patch "Refactor code in tablecmds.c to check and process tablespace moves" Back-patch commits 4c9c359d38ff1e2de388eedd860785be6a49201c and 24843297a96d7be16cc3f4b090aacfc6e5e6839e to v13 and v12. Before those commits, we held the modifiable copy of the relation's pg_class row throughout a table_relation_copy_data(). That can last long enough to copy MaxBlockNumber of data. A subsequent fix will hold LockTuple() for the lifespan of that modifiable copy. By back-patching this first, we avoid a needless long-duration LOCKTAG_TUPLE. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1299564cb9c787de3068777eaf8440fd0fceca4a Modified Files -- src/backend/commands/tablecmds.c | 210 ++- src/include/commands/tablecmds.h | 4 + 2 files changed, 123 insertions(+), 91 deletions(-)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b779d37a3db2555a1d6c571c09eeabfe1c5caeb5 Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ src/include/storage/lock.h | 1 + 2 files changed, 11 insertions(+)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cafcc3ad0ed324993211b0dce09362aad3165146 Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 14 +- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execReplication.c | 7 +- src/backend/executor/nodeModifyTable.c | 26 src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 17 files changed, 423 insertions(+), 34 deletions(-)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3b7a689e1a805c4dac2f35ff14fd5c9fdbddf150 Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 25 +++- src/backend/commands/event_trigger.c | 7 +- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execMain.c| 6 + src/backend/executor/execReplication.c | 6 +- src/backend/executor/nodeModifyTable.c | 98 +++--- src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/nodes/execnodes.h | 3 + src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 20 files changed, 498 insertions(+), 57 deletions(-)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5ef9b4a2f79670a1cf9649e568fba7920a72e9a4 Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c837f8fa022ff9d9ebced71fdcae273fe433570 Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 25 +++- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execMain.c| 7 + src/backend/executor/execReplication.c | 7 +- src/backend/executor/nodeModifyTable.c | 87 ++-- src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/nodes/execnodes.h | 3 + src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 19 files changed, 490 insertions(+), 49 deletions(-)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dbf3f974ee04d24547690268b1fc2b7eb12b4ebc Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/41e0ba33d5ab2b2301aa5d932836927bf69a76a8 Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/82c2d9e0220666ff698c226db41cb119ed4bfa44 Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 252 +++-- src/backend/access/index/genam.c | 137 +++ src/backend/catalog/index.c| 38 +--- src/backend/catalog/toasting.c | 31 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 7 + .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- 13 files changed, 486 insertions(+), 96 deletions(-)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/51ff46de29f67d73549b2858f57e77ada8513369 Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 25 +++- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execMain.c| 6 + src/backend/executor/execReplication.c | 6 +- src/backend/executor/nodeModifyTable.c | 87 ++-- src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/nodes/execnodes.h | 3 + src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 19 files changed, 488 insertions(+), 49 deletions(-)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/14c57cb63907eb7af0f973022b919c0f777db0d9 Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 14 +- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execReplication.c | 7 +- src/backend/executor/nodeModifyTable.c | 26 src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 17 files changed, 423 insertions(+), 34 deletions(-)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/acc63ef4fbe686b0a21000d391d42bbf6b8296eb Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a07e03fd8fa7daf4d1356f7cb501ffe784ea6257 Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 226 src/backend/access/index/genam.c | 137 ++ src/backend/catalog/index.c| 38 +-- src/backend/catalog/toasting.c | 30 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/event_trigger.c | 27 +- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 8 +- .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- .../modules/injection_points/expected/inplace.out | 299 - .../modules/injection_points/specs/inplace.spec| 74 - 16 files changed, 801 insertions(+), 155 deletions(-)
pgsql: Fix data loss at inplace update after heap_update().
Fix data loss at inplace update after heap_update(). As previously-added tests demonstrated, heap_inplace_update() could instead update an unrelated tuple of the same catalog. It could lose the update. Losing relhasindex=t was a source of index corruption. Inplace-updating commands like VACUUM will now wait for heap_update() commands like GRANT TABLE and GRANT DATABASE. That isn't ideal, but a long-running GRANT already hurts VACUUM progress more just by keeping an XID running. The VACUUM will behave like a DELETE or UPDATE waiting for the uncommitted change. For implementation details, start at the systable_inplace_update_begin() header comment and README.tuplock. Back-patch to v12 (all supported versions). In back branches, retain a deprecated heap_inplace_update(), for extensions. Reported by Smolkin Grigory. Reviewed by Nitin Motiani, (in earlier versions) Heikki Linnakangas, and (in earlier versions) Alexander Lakhin. Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bg2mgqecerqr5gg...@mail.gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fd27b878c2ea54b6132758084270cb13e5e66f2e Modified Files -- src/backend/access/heap/README.tuplock | 11 + src/backend/access/heap/heapam.c | 254 +++-- src/backend/access/index/genam.c | 139 ++ src/backend/catalog/index.c| 38 +-- src/backend/catalog/toasting.c | 30 ++- src/backend/commands/dbcommands.c | 34 +-- src/backend/commands/event_trigger.c | 27 +- src/backend/commands/vacuum.c | 32 ++- src/include/access/genam.h | 9 + src/include/access/heapam.h| 7 + .../isolation/expected/intra-grant-inplace-db.out | 10 +- .../isolation/expected/intra-grant-inplace.out | 16 +- .../isolation/specs/intra-grant-inplace-db.spec| 1 - src/test/isolation/specs/intra-grant-inplace.spec | 4 +- .../modules/injection_points/expected/inplace.out | 299 - .../modules/injection_points/specs/inplace.spec| 74 - 16 files changed, 862 insertions(+), 123 deletions(-)
pgsql: For inplace update durability, make heap_update() callers wait.
For inplace update durability, make heap_update() callers wait. The previous commit fixed some ways of losing an inplace update. It remained possible to lose one when a backend working toward a heap_update() copied a tuple into memory just before inplace update of that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE to govern admission to the steps of copying an old tuple, modifying it, and issuing heap_update(). This includes MERGE commands. To avoid changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when holding a relation lock sufficient to exclude inplace updaters. Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE pg_class" or "UPDATE pg_database" can still lose an inplace update. The v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35, and it wasn't worth reimplementing that fix without such infrastructure. Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f51b34b3eddbc501063f7b8ac470d26ce4e18a48 Modified Files -- src/backend/access/heap/README.tuplock | 42 ++ src/backend/access/heap/heapam.c | 150 - src/backend/access/index/genam.c | 4 +- src/backend/catalog/aclchk.c | 9 +- src/backend/catalog/catalog.c | 9 ++ src/backend/commands/dbcommands.c | 14 +- src/backend/commands/indexcmds.c | 7 +- src/backend/commands/tablecmds.c | 28 +++- src/backend/executor/execMain.c| 7 + src/backend/executor/execReplication.c | 7 +- src/backend/executor/nodeModifyTable.c | 30 + src/backend/utils/cache/relcache.c | 9 +- src/backend/utils/cache/syscache.c | 117 src/include/nodes/execnodes.h | 3 + src/include/storage/lockdefs.h | 2 + src/include/utils/syscache.h | 5 + .../isolation/expected/intra-grant-inplace.out | 14 +- src/test/isolation/specs/eval-plan-qual.spec | 2 +- src/test/isolation/specs/intra-grant-inplace.spec | 12 +- 19 files changed, 437 insertions(+), 34 deletions(-)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c9de1b8ac8df344ea08316f2f7edd86b912d6b1c Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta
Back-patch "Refactor code in tablecmds.c to check and process tablespace moves" Back-patch commits 4c9c359d38ff1e2de388eedd860785be6a49201c and 24843297a96d7be16cc3f4b090aacfc6e5e6839e to v13 and v12. Before those commits, we held the modifiable copy of the relation's pg_class row throughout a table_relation_copy_data(). That can last long enough to copy MaxBlockNumber of data. A subsequent fix will hold LockTuple() for the lifespan of that modifiable copy. By back-patching this first, we avoid a needless long-duration LOCKTAG_TUPLE. Discussion: https://postgr.es/m/20231027214946.79.nmi...@google.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc845383cd12dcbb09b468b2eea94bf549528a4b Modified Files -- src/backend/commands/tablecmds.c | 210 ++- src/include/commands/tablecmds.h | 4 + 2 files changed, 123 insertions(+), 91 deletions(-)
pgsql: Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions. The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f33bf1c7d501af56b257256349990ad9000dcffa Modified Files -- src/backend/storage/lmgr/lock.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/507b72bd9f7de95a224ae5af8797f42bfce1ed9c Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/916b8ae475fa852483a7ef05e793a22c922bf999 Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c698e8987dbaf1d5079f451f1379abed3725c0c Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6f6521de9a961e9365bc84e95a04a7afaafb2f95 Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ac04aa84a7f06635748278e6ff4bd74751bb3e8e Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2370582ab14f179eb8edd748d629edf99189 Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Don't enter parallel mode when holding interrupts.
Don't enter parallel mode when holding interrupts. Doing so caused the leader to hang in wait_event=ParallelFinish, which required an immediate shutdown to resolve. Back-patch to v12 (all supported versions). Francesco Degrassi Discussion: https://postgr.es/m/CAC-SaSzHUKT=vzj8mpxydc_urpfax+yoa1hktcf4roz_q6z...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/884860bfc0286ca35f7c097c2511bad90f4ede07 Modified Files -- src/backend/optimizer/plan/planner.c | 6 ++ src/test/regress/expected/select_parallel.out | 24 + src/test/regress/sql/select_parallel.sql | 31 +++ 3 files changed, 61 insertions(+)
pgsql: Optimize pg_visibility with read streams.
Optimize pg_visibility with read streams. We've measured 5% performance improvement, and this arranges to benefit automatically from future optimizations to the read_stream subsystem. The area lacked test coverage, so close that gap. Nazir Bilal Yavuz Discussion: https://postgr.es/m/can55fz1_ru3xpmgtwsu67fth2fs_frrromb7x6zs+f44qbe...@mail.gmail.com Discussion: https://postgr.es/m/caeudqaozv3wty5tv2t29jcwpydbmkbiwqkzd42s2ogzdixp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/65c310b310a613d86c1ba94891fa9972587e09fd Modified Files -- contrib/pg_visibility/meson.build | 1 + contrib/pg_visibility/pg_visibility.c | 113 -- contrib/pg_visibility/t/002_corrupt_vm.pl | 109 3 files changed, 202 insertions(+), 21 deletions(-)
pgsql: Revert "Optimize pg_visibility with read streams."
Revert "Optimize pg_visibility with read streams." This reverts commit ed1b1ee59fb3792baa32f669333b75024ef01bcc and its followup 1c61fd8b527954f0ec522e5e60a11ce82628b681. They rendered collect_corrupt_items() unable to detect corruption. Discussion: https://postgr.es/m/can55fz1_ru3xpmgtwsu67fth2fs_frrromb7x6zs+f44qbe...@mail.gmail.com Discussion: https://postgr.es/m/caeudqaozv3wty5tv2t29jcwpydbmkbiwqkzd42s2ogzdixp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ddfc556a644404a8942e77651f75f09aa5188782 Modified Files -- contrib/pg_visibility/pg_visibility.c | 113 +++--- 1 file changed, 21 insertions(+), 92 deletions(-)
pgsql: Fix stack variable scope from previous commit.
Fix stack variable scope from previous commit. The defect came from me, not from that commit's credited author. Per buildfarm members olingo and grassquit. Discussion: https://postgr.es/m/20240903192030...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1c61fd8b527954f0ec522e5e60a11ce82628b681 Modified Files -- contrib/pg_visibility/pg_visibility.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Add block_range_read_stream_cb(), to deduplicate code.
Add block_range_read_stream_cb(), to deduplicate code. This replaces two functions for iterating over all blocks in a range. A pending patch will use this instead of adding a third. Nazir Bilal Yavuz Discussion: https://postgr.es/m/20240820184742.f2.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c582b75851c2d096ce050d753494505a957cee75 Modified Files -- contrib/pg_prewarm/pg_prewarm.c | 27 --- src/backend/storage/aio/read_stream.c | 17 + src/backend/storage/buffer/bufmgr.c | 35 --- src/include/storage/read_stream.h | 10 ++ src/tools/pgindent/typedefs.list | 1 + 5 files changed, 36 insertions(+), 54 deletions(-)
pgsql: Optimize pg_visibility with read streams.
Optimize pg_visibility with read streams. We've measured 5% performance improvement, and this arranges to benefit automatically from future optimizations to the read_stream subsystem. Nazir Bilal Yavuz Discussion: https://postgr.es/m/can55fz1_ru3xpmgtwsu67fth2fs_frrromb7x6zs+f44qbe...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ed1b1ee59fb3792baa32f669333b75024ef01bcc Modified Files -- contrib/pg_visibility/pg_visibility.c | 114 +++--- 1 file changed, 93 insertions(+), 21 deletions(-)
pgsql: Fix attach of a previously-detached injection point.
Fix attach of a previously-detached injection point. It's normal for the name in a free slot to match the new name. The max_inuse mechanism kept simple cases from reaching the problem. The problem could appear when index 0 was the previously-detached entry and index 1 is in use. Back-patch to v17, where this code first appeared. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a36aa223ec447276bf7050ab9ec6d974cafdf6c4 Modified Files -- src/backend/utils/misc/injection_point.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Fix attach of a previously-detached injection point.
Fix attach of a previously-detached injection point. It's normal for the name in a free slot to match the new name. The max_inuse mechanism kept simple cases from reaching the problem. The problem could appear when index 0 was the previously-detached entry and index 1 is in use. Back-patch to v17, where this code first appeared. Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6b1f78d90b5f2475d968e16febee8f9d43730d63 Modified Files -- src/backend/utils/misc/injection_point.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Fix comments on wal_level=minimal, CREATE TABLESPACE and CREATE
Fix comments on wal_level=minimal, CREATE TABLESPACE and CREATE DATABASE. Commit 97ddda8a82ac470ae581d0eb485b6577707678bc removed the rmtree() behavior from XLOG_TBLSPC_CREATE, obsoleting that part of the comment. The comment's point about XLOG_DBASE_CREATE was wrong when commit fa0f466d5329e10b16f3b38c8eaf5306f7e234e8 introduced the point. (It would have been accurate if that commit had predated commit fbcbc5d06f53aea412130deb52e216aa3883fb8d introducing the second checkpoint of CREATE DATABASE.) Nothing can skip log_smgrcreate() on the basis of wal_level=minimal, so don't comment on that. Commit c6b92041d38512a4176ed76ad06f713d2e6c01a8 expanded WAL skipping from five specific operations to relfilenodes generally, hence the CreateDatabaseUsingFileCopy() comment change. Discussion: https://postgr.es/m/20231008022204...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/64740853f07fd1a8314ad68c38298d7e5afe1acc Modified Files -- src/backend/access/heap/heapam_handler.c | 4 +--- src/backend/commands/dbcommands.c| 7 --- 2 files changed, 5 insertions(+), 6 deletions(-)
pgsql: Teach RPM the package name provided in Perl alias packages.
Teach RPM the package name provided in Perl alias packages. When commit 1185be355462d1dc7e2950a7e52eb7ca0cb6f3c8 introduced installation of a file containing "use PostgreSQL::Test::Utils", the RPM Package Manager said "nothing provides perl(PostgreSQL::Test::Utils)". Discussed on pgsql-packagers. Back-patch to v12, v13, and v14 only; newer versions don't have the alias packages. Reviewed by Andrew Dunstan, Tom Lane, and John Harvey. Reported by John Harvey. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ecf7c48462396b98c50d32cc77ec5a024fefc34c Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 6 ++ src/test/perl/PostgreSQL/Test/Utils.pm | 6 ++ 2 files changed, 12 insertions(+)
pgsql: Fix names of "Visual Studio" and Meson in a documentation senten
Fix names of "Visual Studio" and Meson in a documentation sentence. Commit 3cffe7946c268be91a340ec9a27081cb93d67d35 missed this. Back-patch to v17, which introduced this. Discussion: https://postgr.es/m/caj7c6tm7ct0ejocqalsvyoxxnew4xcufebwj77gktwsqedy...@mail.gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/75345f6985f2d202e43b4fd5ad9e73908c257445 Modified Files -- doc/src/sgml/installation.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Teach RPM the package name provided in Perl alias packages.
Teach RPM the package name provided in Perl alias packages. When commit 1185be355462d1dc7e2950a7e52eb7ca0cb6f3c8 introduced installation of a file containing "use PostgreSQL::Test::Utils", the RPM Package Manager said "nothing provides perl(PostgreSQL::Test::Utils)". Discussed on pgsql-packagers. Back-patch to v12, v13, and v14 only; newer versions don't have the alias packages. Reviewed by Andrew Dunstan, Tom Lane, and John Harvey. Reported by John Harvey. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/382909b635cb0eb164ef678b68b0cc4ecfb26d6b Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 6 ++ src/test/perl/PostgreSQL/Test/Utils.pm | 6 ++ 2 files changed, 12 insertions(+)
pgsql: Fix names of "Visual Studio" and Meson in a documentation senten
Fix names of "Visual Studio" and Meson in a documentation sentence. Commit 3cffe7946c268be91a340ec9a27081cb93d67d35 missed this. Back-patch to v17, which introduced this. Discussion: https://postgr.es/m/caj7c6tm7ct0ejocqalsvyoxxnew4xcufebwj77gktwsqedy...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e56ccc8e4204d9faf86f3bd2e435a0788b3d0429 Modified Files -- doc/src/sgml/installation.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Teach RPM the package name provided in Perl alias packages.
Teach RPM the package name provided in Perl alias packages. When commit 1185be355462d1dc7e2950a7e52eb7ca0cb6f3c8 introduced installation of a file containing "use PostgreSQL::Test::Utils", the RPM Package Manager said "nothing provides perl(PostgreSQL::Test::Utils)". Discussed on pgsql-packagers. Back-patch to v12, v13, and v14 only; newer versions don't have the alias packages. Reviewed by Andrew Dunstan, Tom Lane, and John Harvey. Reported by John Harvey. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/646b16bcafeaa98d7a085ccf4bef11dfc0999fb8 Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 6 ++ src/test/perl/PostgreSQL/Test/Utils.pm | 6 ++ 2 files changed, 12 insertions(+)
pgsql: Fix name of "Visual Studio" in documentation.
Fix name of "Visual Studio" in documentation. Back-patch to v17, which introduced this. Aleksander Alekseev Discussion: https://postgr.es/m/caj7c6tm7ct0ejocqalsvyoxxnew4xcufebwj77gktwsqedy...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3cffe7946c268be91a340ec9a27081cb93d67d35 Modified Files -- doc/src/sgml/installation.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix name of "Visual Studio" in documentation.
Fix name of "Visual Studio" in documentation. Back-patch to v17, which introduced this. Aleksander Alekseev Discussion: https://postgr.es/m/caj7c6tm7ct0ejocqalsvyoxxnew4xcufebwj77gktwsqedy...@mail.gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c175c9202d730df366f21c1aaac1a165bb98c065 Modified Files -- doc/src/sgml/installation.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix private struct field name to match the code using it.
Fix private struct field name to match the code using it. Commit 8720a15e9ab121e49174d889eaeafae8ac89de7b added the wrong name. Nazir Bilal Yavuz Discussion: https://postgr.es/m/20240720181405.5a.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/840b3b5b4ee90ce8b692519e534dfb015d89fe8f Modified Files -- src/backend/storage/buffer/bufmgr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove "smgr_persistence == 0" dead code.
Remove "smgr_persistence == 0" dead code. Reaching that code would have required multiple processes performing relation extension during recovery, which does not happen. That caller has the persistence available, so pass it. This was dead code as soon as commit 210622c60e1a9db2e2730140b8106ab57d259d15 added it. Discussion: https://postgr.es/m/CAN55FZ0JKL6vk1xQp6rfOXiNFV1u1H0tJDPPGHWoiO3ea2Wc=a...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e00c45f6850f86c53b48478f60c15be905dc914d Modified Files -- src/backend/storage/buffer/bufmgr.c | 10 +- src/include/storage/bufmgr.h| 10 +++--- 2 files changed, 4 insertions(+), 16 deletions(-)
pgsql: Use read streams in CREATE DATABASE when STRATEGY=WAL_LOG.
Use read streams in CREATE DATABASE when STRATEGY=WAL_LOG. While this doesn't significantly change runtime now, it arranges for STRATEGY=WAL_LOG to benefit automatically from future optimizations to the read_stream subsystem. For large tables in the template database, this does read 16x as many bytes per system call. Platforms with high per-call overhead, if any, may see an immediate benefit. Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0JKL6vk1xQp6rfOXiNFV1u1H0tJDPPGHWoiO3ea2Wc=a...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8720a15e9ab121e49174d889eaeafae8ac89de7b Modified Files -- src/backend/storage/buffer/bufmgr.c | 53 ++--- 1 file changed, 49 insertions(+), 4 deletions(-)
pgsql: Refactor PinBufferForBlock() to remove checks about persistence.
Refactor PinBufferForBlock() to remove checks about persistence. There are checks in PinBufferForBlock() function to set persistence of the relation. This function is called for each block in the relation. Instead, set persistence of the relation before PinBufferForBlock(). Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0JKL6vk1xQp6rfOXiNFV1u1H0tJDPPGHWoiO3ea2Wc=a...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/af07a827b9c579be64f144f88e03bff3bb85582c Modified Files -- src/backend/storage/aio/read_stream.c | 2 +- src/backend/storage/buffer/bufmgr.c | 27 +++ src/include/storage/bufmgr.h | 2 +- 3 files changed, 17 insertions(+), 14 deletions(-)
pgsql: Add a way to create read stream object by using SMgrRelation.
Add a way to create read stream object by using SMgrRelation. Currently read stream object can be created only by using Relation. Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0JKL6vk1xQp6rfOXiNFV1u1H0tJDPPGHWoiO3ea2Wc=a...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a858be17c3f85a2ce3ad5e3073c14ab948b85079 Modified Files -- src/backend/storage/aio/read_stream.c | 76 --- src/include/storage/read_stream.h | 10 + 2 files changed, 72 insertions(+), 14 deletions(-)
pgsql: Fix new assertion for MERGE view_name ... DO NOTHING.
Fix new assertion for MERGE view_name ... DO NOTHING. Such queries don't expand automatically updatable views, and ModifyTable uses the wholerow attribute unconditionally. The user-visible behavior is fine, so change to more-specific assertions. Commit d5f788b41dc2cbdde6e7694c70dda54d829a5ed5 added the wrong assertion. Back-patch to v17, where commit 5f2e179bd31e5f5803005101eb12a8d7bf8db8f3 introduced MERGE view_name. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/e4b40a88-c134-6926-3196-bc4501cb8...@gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0d3b35c367c21fcfe437b689919bf153f85e2e25 Modified Files -- src/backend/executor/nodeModifyTable.c| 40 +++ src/test/regress/expected/updatable_views.out | 5 src/test/regress/sql/updatable_views.sql | 5 3 files changed, 33 insertions(+), 17 deletions(-)
pgsql: Don't lose partitioned table reltuples=0 after relhassubclass=f.
Don't lose partitioned table reltuples=0 after relhassubclass=f. ANALYZE sets relhassubclass=f when a partitioned table no longer has partitions. An ANALYZE doing that proceeded to apply the inplace update of pg_class.reltuples to the old pg_class tuple instead of the new tuple, losing that reltuples=0 change if the ANALYZE committed. Non-partitioning inheritance trees were unaffected. Back-patch to v14, where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced maintenance of partitioned table pg_class.reltuples. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/a295b499-dcab-6a99-c06e-01cf60593...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7102070329d8147246d2791321f9915c3b5abf31 Modified Files -- src/backend/commands/analyze.c | 7 +- src/test/regress/expected/vacuum.out | 47 src/test/regress/sql/vacuum.sql | 29 ++ 3 files changed, 82 insertions(+), 1 deletion(-)
pgsql: Don't lose partitioned table reltuples=0 after relhassubclass=f.
Don't lose partitioned table reltuples=0 after relhassubclass=f. ANALYZE sets relhassubclass=f when a partitioned table no longer has partitions. An ANALYZE doing that proceeded to apply the inplace update of pg_class.reltuples to the old pg_class tuple instead of the new tuple, losing that reltuples=0 change if the ANALYZE committed. Non-partitioning inheritance trees were unaffected. Back-patch to v14, where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced maintenance of partitioned table pg_class.reltuples. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/a295b499-dcab-6a99-c06e-01cf60593...@gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2b415e95a8a7ccb4fe9276e2ca453f4ae69466c1 Modified Files -- src/backend/commands/analyze.c | 7 - src/test/regress/expected/sanity_check.out | 2 ++ src/test/regress/expected/vacuum.out | 47 ++ src/test/regress/sql/vacuum.sql| 29 ++ 4 files changed, 84 insertions(+), 1 deletion(-)
pgsql: Don't lose partitioned table reltuples=0 after relhassubclass=f.
Don't lose partitioned table reltuples=0 after relhassubclass=f. ANALYZE sets relhassubclass=f when a partitioned table no longer has partitions. An ANALYZE doing that proceeded to apply the inplace update of pg_class.reltuples to the old pg_class tuple instead of the new tuple, losing that reltuples=0 change if the ANALYZE committed. Non-partitioning inheritance trees were unaffected. Back-patch to v14, where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced maintenance of partitioned table pg_class.reltuples. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/a295b499-dcab-6a99-c06e-01cf60593...@gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2b4a2a79edd258e13a44601d17b44e9929abab14 Modified Files -- src/backend/commands/analyze.c | 7 +- src/test/regress/expected/vacuum.out | 47 src/test/regress/sql/vacuum.sql | 29 ++ 3 files changed, 82 insertions(+), 1 deletion(-)
pgsql: Don't lose partitioned table reltuples=0 after relhassubclass=f.
Don't lose partitioned table reltuples=0 after relhassubclass=f. ANALYZE sets relhassubclass=f when a partitioned table no longer has partitions. An ANALYZE doing that proceeded to apply the inplace update of pg_class.reltuples to the old pg_class tuple instead of the new tuple, losing that reltuples=0 change if the ANALYZE committed. Non-partitioning inheritance trees were unaffected. Back-patch to v14, where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced maintenance of partitioned table pg_class.reltuples. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/a295b499-dcab-6a99-c06e-01cf60593...@gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f5bb46fb2e65f951fe22c166756dab9743b33a8a Modified Files -- src/backend/commands/analyze.c | 7 +- src/test/regress/expected/vacuum.out | 47 src/test/regress/sql/vacuum.sql | 29 ++ 3 files changed, 82 insertions(+), 1 deletion(-)
pgsql: Don't lose partitioned table reltuples=0 after relhassubclass=f.
Don't lose partitioned table reltuples=0 after relhassubclass=f. ANALYZE sets relhassubclass=f when a partitioned table no longer has partitions. An ANALYZE doing that proceeded to apply the inplace update of pg_class.reltuples to the old pg_class tuple instead of the new tuple, losing that reltuples=0 change if the ANALYZE committed. Non-partitioning inheritance trees were unaffected. Back-patch to v14, where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced maintenance of partitioned table pg_class.reltuples. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/a295b499-dcab-6a99-c06e-01cf60593...@gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e81deeefcac2a0de06f51e82405f63935f00e2bc Modified Files -- src/backend/commands/analyze.c | 7 +- src/test/regress/expected/vacuum.out | 47 src/test/regress/sql/vacuum.sql | 29 ++ 3 files changed, 82 insertions(+), 1 deletion(-)
pgsql: Fix new assertion for MERGE view_name ... DO NOTHING.
Fix new assertion for MERGE view_name ... DO NOTHING. Such queries don't expand automatically updatable views, and ModifyTable uses the wholerow attribute unconditionally. The user-visible behavior is fine, so change to more-specific assertions. Commit d5f788b41dc2cbdde6e7694c70dda54d829a5ed5 added the wrong assertion. Back-patch to v17, where commit 5f2e179bd31e5f5803005101eb12a8d7bf8db8f3 introduced MERGE view_name. Reported by Alexander Lakhin. Discussion: https://postgr.es/m/e4b40a88-c134-6926-3196-bc4501cb8...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d5e6891502ca9e359aa5f5a381d904fe9d606338 Modified Files -- src/backend/executor/nodeModifyTable.c| 40 +++ src/test/regress/expected/updatable_views.out | 5 src/test/regress/sql/updatable_views.sql | 5 3 files changed, 33 insertions(+), 17 deletions(-)
pgsql: Fix .gitignore for new injection suite.
Fix .gitignore for new injection suite. Commit c35f419d6efbdf1a050250d84b687e6705917711 missed this. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/db0c96cc18aec417101e37e59fcc53d4bf647915 Modified Files -- src/test/modules/injection_points/.gitignore | 1 + 1 file changed, 1 insertion(+)
pgsql: Remove configuration-dependent output from new inplace-inval tes
Remove configuration-dependent output from new inplace-inval test. Per buildfarm members prion and trilobite. Back-patch to v12 (all supported versions), like commit 0844b3968985447ed0a6937cfc8639e379da2fe6. Strategy reviewed by Tom Lane. Discussion: https://postgr.es/m/20240628051353.a0.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/458fada72b3288d648a559a17c5a69f1d17ae15f Modified Files -- src/test/isolation/expected/inplace-inval.out | 10 +- src/test/isolation/specs/inplace-inval.spec | 4 +++- 2 files changed, 4 insertions(+), 10 deletions(-)
pgsql: Remove configuration-dependent output from new inplace-inval tes
Remove configuration-dependent output from new inplace-inval test. Per buildfarm members prion and trilobite. Back-patch to v12 (all supported versions), like commit 0844b3968985447ed0a6937cfc8639e379da2fe6. Strategy reviewed by Tom Lane. Discussion: https://postgr.es/m/20240628051353.a0.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ca30e8ba958a60b9179f018052cc8959d38ffa8e Modified Files -- src/test/isolation/expected/inplace-inval.out | 10 +- src/test/isolation/specs/inplace-inval.spec | 4 +++- 2 files changed, 4 insertions(+), 10 deletions(-)
pgsql: Remove configuration-dependent output from new inplace-inval tes
Remove configuration-dependent output from new inplace-inval test. Per buildfarm members prion and trilobite. Back-patch to v12 (all supported versions), like commit 0844b3968985447ed0a6937cfc8639e379da2fe6. Strategy reviewed by Tom Lane. Discussion: https://postgr.es/m/20240628051353.a0.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b99414de90520e9605dff9cb645a2a228876862f Modified Files -- src/test/isolation/expected/inplace-inval.out | 10 +- src/test/isolation/specs/inplace-inval.spec | 4 +++- 2 files changed, 4 insertions(+), 10 deletions(-)
pgsql: Remove configuration-dependent output from new inplace-inval tes
Remove configuration-dependent output from new inplace-inval test. Per buildfarm members prion and trilobite. Back-patch to v12 (all supported versions), like commit 0844b3968985447ed0a6937cfc8639e379da2fe6. Strategy reviewed by Tom Lane. Discussion: https://postgr.es/m/20240628051353.a0.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7857c8dc4481970c27a44a4d1073064ff674b1de Modified Files -- src/test/isolation/expected/inplace-inval.out | 10 +- src/test/isolation/specs/inplace-inval.spec | 4 +++- 2 files changed, 4 insertions(+), 10 deletions(-)
pgsql: Remove configuration-dependent output from new inplace-inval tes
Remove configuration-dependent output from new inplace-inval test. Per buildfarm members prion and trilobite. Back-patch to v12 (all supported versions), like commit 0844b3968985447ed0a6937cfc8639e379da2fe6. Strategy reviewed by Tom Lane. Discussion: https://postgr.es/m/20240628051353.a0.nmi...@google.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/79567599cd2166867fd0057363800d0604f4fc64 Modified Files -- src/test/isolation/expected/inplace-inval.out | 10 +- src/test/isolation/specs/inplace-inval.spec | 4 +++- 2 files changed, 4 insertions(+), 10 deletions(-)
pgsql: Remove configuration-dependent output from new inplace-inval tes
Remove configuration-dependent output from new inplace-inval test. Per buildfarm members prion and trilobite. Back-patch to v12 (all supported versions), like commit 0844b3968985447ed0a6937cfc8639e379da2fe6. Strategy reviewed by Tom Lane. Discussion: https://postgr.es/m/20240628051353.a0.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f31c1e34bc801b57bbc3108725f13b793d7c4a4c Modified Files -- src/test/isolation/expected/inplace-inval.out | 10 +- src/test/isolation/specs/inplace-inval.spec | 4 +++- 2 files changed, 4 insertions(+), 10 deletions(-)
pgsql: AccessExclusiveLock new relations just after assigning the OID.
AccessExclusiveLock new relations just after assigning the OID. This has no user-visible, important consequences, since other sessions' catalog scans can't find the relation until we commit. However, this unblocks introducing a rule about locks required to heap_update() a pg_class row. CREATE TABLE has been acquiring this lock eventually, but it can heap_update() pg_class.relchecks earlier. create_toast_table() has been acquiring only ShareLock. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b899cde0b86acfeb6310489ab6c478059075a8f4 Modified Files -- src/backend/catalog/heap.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Cope with inplace update making catcache stale during TOAST fetc
Cope with inplace update making catcache stale during TOAST fetch. This extends ad98fb14226ae6456fbaed7990ee7591cbe5efd2 to invals of inplace updates. Trouble requires an inplace update of a catalog having a TOAST table, so only pg_database was at risk. (The other catalog on which core code performs inplace updates, pg_class, has no TOAST table.) Trouble would require something like the inplace-inval.spec test. Consider GRANT ... ON DATABASE fetching a stale row from cache and discarding a datfrozenxid update that vac_truncate_clog() has already relied upon. Back-patch to v12 (all supported versions). Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240114201411...@rfd.leadboat.com Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7a21306aee0ac55d931e3da618735a75bda67245 Modified Files -- src/backend/catalog/catalog.c | 21 ++ src/backend/utils/cache/catcache.c | 44 +++--- src/include/catalog/catalog.h | 2 ++ 3 files changed, 64 insertions(+), 3 deletions(-)
pgsql: Make TAP todo_start effects the same under Meson and prove_check
Make TAP todo_start effects the same under Meson and prove_check. This could have caused spurious failures only on SPARC Linux, because today's only todo_start tests for that platform. Back-patch to v16, where Meson support first appeared. Reviewed by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/288426902ee54a22d22ede769d14c5b7d4b59d99 Modified Files -- src/tools/testwrap | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-)
pgsql: Cope with inplace update making catcache stale during TOAST fetc
Cope with inplace update making catcache stale during TOAST fetch. This extends ad98fb14226ae6456fbaed7990ee7591cbe5efd2 to invals of inplace updates. Trouble requires an inplace update of a catalog having a TOAST table, so only pg_database was at risk. (The other catalog on which core code performs inplace updates, pg_class, has no TOAST table.) Trouble would require something like the inplace-inval.spec test. Consider GRANT ... ON DATABASE fetching a stale row from cache and discarding a datfrozenxid update that vac_truncate_clog() has already relied upon. Back-patch to v12 (all supported versions). Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240114201411...@rfd.leadboat.com Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b08a4b6163ebb10d0fcfabbccd49eeb23cef70d3 Modified Files -- src/backend/catalog/catalog.c | 21 ++ src/backend/utils/cache/catcache.c | 44 +++--- src/include/catalog/catalog.h | 2 ++ 3 files changed, 64 insertions(+), 3 deletions(-)
pgsql: Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX.
Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX. Commit 5b562644fec696977df4a82790064e8287927891 added a comment that SetRelationHasSubclass() callers must hold this lock. When commit 17f206fbc824d2b4b14480199ca9ff7dea417eda extended use of this column to partitioned indexes, it didn't take the lock. As the latter commit message mentioned, we currently never reset a partitioned index to relhassubclass=f. That largely avoids harm from the lock omission. The cause for fixing this now is to unblock introducing a rule about locks required to heap_update() a pg_class row. This might cause more deadlocks. It gives minor user-visible benefits: - If an ALTER INDEX SET TABLESPACE runs concurrently with ALTER TABLE ATTACH PARTITION or CREATE PARTITION OF, one transaction blocks instead of failing with "tuple concurrently updated". (Many cases of DDL concurrency still fail that way.) - Match ALTER INDEX ATTACH PARTITION in choosing to lock the index. While not user-visible today, we'll need this if we ever make something set the flag to false for a partitioned index, like ANALYZE does today for tables. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. In back branches, add LockOrStrongerHeldByMe() instead of adding a LockHeldByMe() parameter. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1a6d65b64e8495280862f5757062eb844d134488 Modified Files -- src/backend/catalog/index.c | 1 + src/backend/commands/indexcmds.c | 3 +++ src/backend/commands/tablecmds.c | 16 +-- src/backend/storage/lmgr/lmgr.c | 40 src/backend/storage/lmgr/lock.c | 44 +++- src/include/storage/lmgr.h | 2 ++ src/include/storage/lock.h | 1 + 7 files changed, 77 insertions(+), 30 deletions(-)
pgsql: Lock owned sequences during ALTER TABLE SET { LOGGED | UNLOGGED
Lock owned sequences during ALTER TABLE SET { LOGGED | UNLOGGED }.
These commands already make the persistence of owned sequences follow
owned table persistence changes. They didn't lock those sequences.
They lost the effect of nextval() calls that other sessions make after
the ALTER TABLE command, before the ALTER TABLE transaction commits.
Fix by acquiring the same lock that ALTER SEQUENCE SET { LOGGED |
UNLOGGED } acquires. This might cause more deadlocks. Back-patch to
v15, where commit 344d62fb9a978a72cf8347f0369b9ee643fd0b31 introduced
unlogged sequences.
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/112d055706bfe653685ec24552429a19830a7ef3
Modified Files
--
src/backend/commands/sequence.c | 7 +++
1 file changed, 7 insertions(+)
pgsql: Improve test coverage for changes to inplace-updated catalogs.
Improve test coverage for changes to inplace-updated catalogs. This covers both regular and inplace changes, since bugs arise at their intersection. Where marked, these witness extant bugs. Back-patch to v12 (all supported versions). Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2d06bdbc0cc34df354fd58a857c1a3a8cf4a9406 Modified Files -- src/bin/pgbench/t/001_pgbench_with_server.pl | 28 +++ src/test/isolation/expected/eval-plan-qual.out | 12 ++ src/test/isolation/expected/inplace-inval.out | 32 +++ .../isolation/expected/intra-grant-inplace-db.out | 28 +++ .../isolation/expected/intra-grant-inplace.out | 225 + src/test/isolation/isolation_schedule | 3 + src/test/isolation/specs/eval-plan-qual.spec | 13 ++ src/test/isolation/specs/inplace-inval.spec| 38 .../isolation/specs/intra-grant-inplace-db.spec| 46 + src/test/isolation/specs/intra-grant-inplace.spec | 153 ++ src/test/regress/expected/database.out | 14 ++ src/test/regress/parallel_schedule | 2 +- src/test/regress/sql/database.sql | 16 ++ 13 files changed, 609 insertions(+), 1 deletion(-)
pgsql: Remove comment about xl_heap_inplace "AT END OF STRUCT".
Remove comment about xl_heap_inplace "AT END OF STRUCT". Commit 2c03216d831160bedd72d45f712601b6f7d03f1c moved the tuple data from there to the buffer-0 data. Back-patch to v12 (all supported versions), the plan for the next change to this struct. Discussion: https://postgr.es/m/20240523000548.58.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2ca8ca4827af253efc2852f65c3f1366b90b5130 Modified Files -- src/include/access/heapam_xlog.h | 1 - 1 file changed, 1 deletion(-)
pgsql: Remove comment about xl_heap_inplace "AT END OF STRUCT".
Remove comment about xl_heap_inplace "AT END OF STRUCT". Commit 2c03216d831160bedd72d45f712601b6f7d03f1c moved the tuple data from there to the buffer-0 data. Back-patch to v12 (all supported versions), the plan for the next change to this struct. Discussion: https://postgr.es/m/20240523000548.58.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4a7f91b3d3141e8898211a5b145b3c210b05c288 Modified Files -- src/include/access/heapam_xlog.h | 1 - 1 file changed, 1 deletion(-)
pgsql: Cope with inplace update making catcache stale during TOAST fetc
Cope with inplace update making catcache stale during TOAST fetch. This extends ad98fb14226ae6456fbaed7990ee7591cbe5efd2 to invals of inplace updates. Trouble requires an inplace update of a catalog having a TOAST table, so only pg_database was at risk. (The other catalog on which core code performs inplace updates, pg_class, has no TOAST table.) Trouble would require something like the inplace-inval.spec test. Consider GRANT ... ON DATABASE fetching a stale row from cache and discarding a datfrozenxid update that vac_truncate_clog() has already relied upon. Back-patch to v12 (all supported versions). Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240114201411...@rfd.leadboat.com Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e4afd7153bd80404bffc4d17b37451d7317ae53e Modified Files -- src/backend/catalog/catalog.c | 21 ++ src/backend/utils/cache/catcache.c | 44 +++--- src/include/catalog/catalog.h | 2 ++ 3 files changed, 64 insertions(+), 3 deletions(-)
pgsql: Improve test coverage for changes to inplace-updated catalogs.
Improve test coverage for changes to inplace-updated catalogs. This covers both regular and inplace changes, since bugs arise at their intersection. Where marked, these witness extant bugs. Back-patch to v12 (all supported versions). Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3c6becd3d18011c7cd018bad5294d6d60f878a5f Modified Files -- src/bin/pgbench/t/001_pgbench_with_server.pl | 28 +++ src/test/isolation/expected/eval-plan-qual.out | 26 +++ src/test/isolation/expected/inplace-inval.out | 32 +++ .../isolation/expected/intra-grant-inplace-db.out | 28 +++ .../isolation/expected/intra-grant-inplace.out | 225 + src/test/isolation/isolation_schedule | 3 + src/test/isolation/specs/eval-plan-qual.spec | 21 ++ src/test/isolation/specs/inplace-inval.spec| 38 .../isolation/specs/intra-grant-inplace-db.spec| 46 + src/test/isolation/specs/intra-grant-inplace.spec | 153 ++ src/test/recovery/t/027_stream_regress.pl | 35 src/test/regress/expected/database.out | 14 ++ src/test/regress/expected/merge.out| 11 + src/test/regress/parallel_schedule | 2 +- src/test/regress/sql/database.sql | 16 ++ src/test/regress/sql/merge.sql | 14 ++ 16 files changed, 691 insertions(+), 1 deletion(-)
pgsql: Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX.
Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX. Commit 5b562644fec696977df4a82790064e8287927891 added a comment that SetRelationHasSubclass() callers must hold this lock. When commit 17f206fbc824d2b4b14480199ca9ff7dea417eda extended use of this column to partitioned indexes, it didn't take the lock. As the latter commit message mentioned, we currently never reset a partitioned index to relhassubclass=f. That largely avoids harm from the lock omission. The cause for fixing this now is to unblock introducing a rule about locks required to heap_update() a pg_class row. This might cause more deadlocks. It gives minor user-visible benefits: - If an ALTER INDEX SET TABLESPACE runs concurrently with ALTER TABLE ATTACH PARTITION or CREATE PARTITION OF, one transaction blocks instead of failing with "tuple concurrently updated". (Many cases of DDL concurrency still fail that way.) - Match ALTER INDEX ATTACH PARTITION in choosing to lock the index. While not user-visible today, we'll need this if we ever make something set the flag to false for a partitioned index, like ANALYZE does today for tables. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. In back branches, add LockOrStrongerHeldByMe() instead of adding a LockHeldByMe() parameter. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/480b58fabd353015319f6621ff8c351bf3a6d520 Modified Files -- src/backend/catalog/index.c | 1 + src/backend/commands/indexcmds.c | 3 +++ src/backend/commands/tablecmds.c | 16 +-- src/backend/storage/lmgr/lmgr.c | 40 src/backend/storage/lmgr/lock.c | 44 +++- src/include/storage/lmgr.h | 2 ++ src/include/storage/lock.h | 1 + 7 files changed, 77 insertions(+), 30 deletions(-)
pgsql: AccessExclusiveLock new relations just after assigning the OID.
AccessExclusiveLock new relations just after assigning the OID. This has no user-visible, important consequences, since other sessions' catalog scans can't find the relation until we commit. However, this unblocks introducing a rule about locks required to heap_update() a pg_class row. CREATE TABLE has been acquiring this lock eventually, but it can heap_update() pg_class.relchecks earlier. create_toast_table() has been acquiring only ShareLock. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fc8c25806e84c38f3920fd3507a389eac34d62a5 Modified Files -- src/backend/catalog/heap.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Expand comments and add an assertion in nodeModifyTable.c.
Expand comments and add an assertion in nodeModifyTable.c. Most comments concern RELKIND_VIEW. One addresses the ExecUpdate() "tupleid" parameter. A later commit will rely on these facts, but they hold already. Back-patch to v12 (all supported versions), the plan for that commit. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d5f788b41dc2cbdde6e7694c70dda54d829a5ed5 Modified Files -- src/backend/executor/nodeModifyTable.c | 70 -- 1 file changed, 41 insertions(+), 29 deletions(-)
pgsql: Make TAP todo_start effects the same under Meson and prove_check
Make TAP todo_start effects the same under Meson and prove_check. This could have caused spurious failures only on SPARC Linux, because today's only todo_start tests for that platform. Back-patch to v16, where Meson support first appeared. Reviewed by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/22a4b104ba70f6f486197ab28a28cd9bcdd4f4ad Modified Files -- src/tools/testwrap | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-)
pgsql: Expand comments and add an assertion in nodeModifyTable.c.
Expand comments and add an assertion in nodeModifyTable.c. Most comments concern RELKIND_VIEW. One addresses the ExecUpdate() "tupleid" parameter. A later commit will rely on these facts, but they hold already. Back-patch to v12 (all supported versions), the plan for that commit. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f8135d8b54ff68f0788779d86edd796efc330ff4 Modified Files -- src/backend/executor/nodeModifyTable.c | 55 -- 1 file changed, 32 insertions(+), 23 deletions(-)
pgsql: Expand comments and add an assertion in nodeModifyTable.c.
Expand comments and add an assertion in nodeModifyTable.c. Most comments concern RELKIND_VIEW. One addresses the ExecUpdate() "tupleid" parameter. A later commit will rely on these facts, but they hold already. Back-patch to v12 (all supported versions), the plan for that commit. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ad4653268c12cd50339dae0de59d9add41138d66 Modified Files -- src/backend/executor/nodeModifyTable.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-)
pgsql: Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX.
Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX. Commit 5b562644fec696977df4a82790064e8287927891 added a comment that SetRelationHasSubclass() callers must hold this lock. When commit 17f206fbc824d2b4b14480199ca9ff7dea417eda extended use of this column to partitioned indexes, it didn't take the lock. As the latter commit message mentioned, we currently never reset a partitioned index to relhassubclass=f. That largely avoids harm from the lock omission. The cause for fixing this now is to unblock introducing a rule about locks required to heap_update() a pg_class row. This might cause more deadlocks. It gives minor user-visible benefits: - If an ALTER INDEX SET TABLESPACE runs concurrently with ALTER TABLE ATTACH PARTITION or CREATE PARTITION OF, one transaction blocks instead of failing with "tuple concurrently updated". (Many cases of DDL concurrency still fail that way.) - Match ALTER INDEX ATTACH PARTITION in choosing to lock the index. While not user-visible today, we'll need this if we ever make something set the flag to false for a partitioned index, like ANALYZE does today for tables. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. In back branches, add LockOrStrongerHeldByMe() instead of adding a LockHeldByMe() parameter. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/578db9c9257de00ee695d670fb7d62b295467fe8 Modified Files -- src/backend/catalog/index.c | 1 + src/backend/commands/indexcmds.c | 3 +++ src/backend/commands/tablecmds.c | 16 +-- src/backend/storage/lmgr/lmgr.c | 40 src/backend/storage/lmgr/lock.c | 44 +++- src/include/storage/lmgr.h | 2 ++ src/include/storage/lock.h | 1 + 7 files changed, 77 insertions(+), 30 deletions(-)
pgsql: Improve test coverage for changes to inplace-updated catalogs.
Improve test coverage for changes to inplace-updated catalogs. This covers both regular and inplace changes, since bugs arise at their intersection. Where marked, these witness extant bugs. Back-patch to v12 (all supported versions). Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmi...@google.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dd8008e8ec956845a3a25060e596994192489f0a Modified Files -- src/bin/pgbench/t/001_pgbench_with_server.pl | 28 +++ src/test/isolation/expected/eval-plan-qual.out | 26 +++ src/test/isolation/expected/inplace-inval.out | 32 +++ .../isolation/expected/intra-grant-inplace-db.out | 28 +++ .../isolation/expected/intra-grant-inplace.out | 225 + src/test/isolation/isolation_schedule | 3 + src/test/isolation/specs/eval-plan-qual.spec | 21 ++ src/test/isolation/specs/inplace-inval.spec| 38 .../isolation/specs/intra-grant-inplace-db.spec| 46 + src/test/isolation/specs/intra-grant-inplace.spec | 153 ++ src/test/recovery/t/027_stream_regress.pl | 34 src/test/regress/expected/database.out | 15 ++ src/test/regress/expected/merge.out| 11 + src/test/regress/parallel_schedule | 2 +- src/test/regress/sql/database.sql | 17 ++ src/test/regress/sql/merge.sql | 14 ++ 16 files changed, 692 insertions(+), 1 deletion(-)
pgsql: AccessExclusiveLock new relations just after assigning the OID.
AccessExclusiveLock new relations just after assigning the OID. This has no user-visible, important consequences, since other sessions' catalog scans can't find the relation until we commit. However, this unblocks introducing a rule about locks required to heap_update() a pg_class row. CREATE TABLE has been acquiring this lock eventually, but it can heap_update() pg_class.relchecks earlier. create_toast_table() has been acquiring only ShareLock. Back-patch to v12 (all supported versions), the plan for the commit relying on the new rule. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmi...@google.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e038b7756df8a7487366d4e678c1e0d0d1ba5bbe Modified Files -- src/backend/catalog/heap.c | 7 +++ 1 file changed, 7 insertions(+)
