pgsql: doc: Clean up title case use
doc: Clean up title case use Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ee685c9baf987984dbd2194d74576422996d95f4 Modified Files -- doc/src/sgml/logical-replication.sgml | 12 ++-- doc/src/sgml/protocol.sgml| 4 ++-- doc/src/sgml/textsearch.sgml | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-)
pgsql: libpq-oauth: Add exports.list to .gitignore
libpq-oauth: Add exports.list to .gitignore Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f24fdf985561e7166d7d54459b764daae8efda44 Modified Files -- src/interfaces/libpq-oauth/.gitignore | 1 + 1 file changed, 1 insertion(+)
pgsql: Message style improvements
Message style improvements Some message style improvements in new code, and some small refactorings to make translations easier. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a876464abc73eccc04543da6a12eb5b1ffcd6dfd Modified Files -- src/bin/pg_basebackup/pg_createsubscriber.c| 12 +++--- src/bin/pg_basebackup/pg_recvlogical.c | 2 +- src/bin/pg_basebackup/t/040_pg_createsubscriber.pl | 4 +- src/bin/pg_dump/pg_dump.c | 8 ++-- src/bin/pg_dump/pg_dumpall.c | 8 ++-- src/bin/pg_dump/pg_restore.c | 43 +- src/bin/pg_dump/t/001_basic.pl | 4 +- src/bin/pg_dump/t/006_pg_dumpall.pl| 2 +- src/bin/pg_upgrade/check.c | 4 +- src/bin/pg_upgrade/relfilenumber.c | 12 +++--- src/bin/pg_upgrade/t/005_char_signedness.pl| 2 +- src/bin/pg_upgrade/task.c | 5 +-- src/bin/psql/command.c | 6 +-- src/bin/psql/describe.c| 5 ++- src/bin/psql/help.c| 6 +-- src/bin/psql/variables.c | 10 ++--- 16 files changed, 70 insertions(+), 63 deletions(-)
pgsql: aio: Add missing memory barrier when waiting for IO handle
aio: Add missing memory barrier when waiting for IO handle Previously there was no memory barrier enforcing correct memory ordering when waiting for a free IO handle. However, in the much more common case of waiting for IO to complete, memory barriers already were present. On strongly ordered architectures like x86 this had no negative consequences, but on some armv8 hardware (observed on Apple hardware), it was possible for the update, in the IO worker, to PgAioHandle->state to become visible before ->distilled_result becoming visible, leading to rather confusing assertion failures. The failures were rare enough that the bug sometimes took days to reproduce when running 027_stream_regress in a loop. Once finally debugged, it was easy enough to come up with a much quicker repro: Trigger a lot of very fast IO by limiting io_combine_limit to 1 and ensure that we always have to wait for a free handle by setting io_max_concurrency to 1. Triggering lots of concurrent seqscans in that setup triggers the issue within seconds. One reason this was hard to debug was that the assertion failure most commonly happened in WaitReadBuffers(), rather than in the AIO subsystem itself. The assertions added in this commit make problems like this easier to understand. Also add a comment to the IO worker explaining that we rely on the lwlock acquisition for correct memory ordering. I think it'd be good to add a tap test that stress tests buffer IO, but that's material for a separate patch. Thanks a lot to Alexander and Konstantin for all the debugging help. Reported-by: Tom Lane Reported-by: Alexander Lakhin Investigated-by: Andres Freund Investigated-by: Alexander Lakhin Investigated-by: Konstantin Knizhnik Discussion: https://postgr.es/m/2dkz7azclpeiqcmouamdixyn5xhlzy4rvikxrbovyzvi6rnv5c@pz7o7osv2ahf Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e9a3615a5224236917af161d9b6a55ba8f129b4d Modified Files -- src/backend/storage/aio/aio.c | 17 + src/backend/storage/aio/aio_callback.c | 7 +++ src/backend/storage/aio/method_worker.c | 7 ++- 3 files changed, 30 insertions(+), 1 deletion(-)
pgsql: doc: Mention the default io_method
doc: Mention the default io_method It was previously not documented. Author: Daniel Westermann (DWE) Reviewed-by: Pavel Stehule Discussion: https://www.postgresql.org/message-id/flat/ZR0P278MB04279CB0C1D8F49DE68F168ED2AF2%40ZR0P278MB0427.CHEP278.PROD.OUTLOOK.COM Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6f55fb741147c49dc20dd2e4597363b2cc04acb4 Modified Files -- doc/src/sgml/config.sgml | 1 + 1 file changed, 1 insertion(+)
pgsql: doc PG 18 relnotes: add author for initdb commit 04bec894a04
doc PG 18 relnotes: add author for initdb commit 04bec894a04 Needed to run src/tools//add_commit_links.pl. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/23c67e8a839441c9d6a307b531a3369b677c91eb Modified Files -- doc/src/sgml/release-18.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix possible Assert failure in verify_compact_attribute()
Fix possible Assert failure in verify_compact_attribute() Sometimes the TupleDesc used in verify_compact_attribute() is shared among backends, and since CompactAttribute.attcacheoff gets updated during tuple deformation, it was possible that another backend would set attcacheoff on a given CompactAttribute in the small window of time from when the attcacheoff from the live CompactAttribute was being set in the 'tmp' CompactAttribute and before the Assert verifying that the live and tmp CompactAttributes matched. Here we adjust the code to make a copy of the live CompactAttribute so that we're not trying to Assert against a shared copy of it. Author: David Rowley Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/7195e408-758c-4031-8e61-4f842c716...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/33b06a20016d8dd8dbdc1f6d6a9d79477c1104c5 Modified Files -- src/backend/access/common/tupdesc.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-)
pgsql: Fix re-distributing previously distributed invalidation messages
Fix re-distributing previously distributed invalidation messages during logical decoding. Commit 4909b38af0 introduced logic to distribute invalidation messages from catalog-modifying transactions to all concurrent in-progress transactions. However, since each transaction distributes not only its original invalidation messages but also previously distributed messages to other transactions, this leads to an exponential increase in allocation request size for invalidation messages, ultimately causing memory allocation failure. This commit fixes this issue by tracking distributed invalidation messages separately per decoded transaction and not redistributing these messages to other in-progress transactions. The maximum size of distributed invalidation messages that one transaction can store is limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the distributed invalidation messages exceeds this threshold, we invalidate all caches in locations where distributed invalidation messages need to be executed. Back-patch to all supported versions where we introduced the fix by commit 4909b38af0. Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. Additionally, it adds a new flag to the txn_flags field of ReorderBufferTXN to indicate distributed invalidation message overflow. This should not affect existing implementations, as it is unlikely that third-party extensions use unused bits in the txn_flags field. Bug: #18938 #18942 Author: vignesh C Reported-by: Duncan Sands Reported-by: John Hutchins Reported-by: Laurence Parry Reported-by: Max Madden Reported-by: Braulio Fdo Gonzalez Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c6...@deepbluecap.com Discussion: https://postgr.es/m/18942-0ab1e5ae15661...@postgresql.org Discussion: https://postgr.es/m/18938-57c9a1c463b68...@postgresql.org Discussion: https://postgr.es/m/cad1fgct2syrp_70rtuo56qtizyc+j3wjdtn2gto3vttqfpd...@mail.gmail.com Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuutnvtnjidmg0+-ffnrnqm6kd23qo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/45c357e0e85d2dffe7af5440806150124a725a01 Modified Files -- .../expected/invalidation_distribution.out | 23 ++- .../specs/invalidation_distribution.spec | 11 ++ src/backend/replication/logical/reorderbuffer.c| 196 + src/backend/replication/logical/snapbuild.c| 12 +- src/include/replication/reorderbuffer.h| 34 +++- 5 files changed, 231 insertions(+), 45 deletions(-)
pgsql: Fix re-distributing previously distributed invalidation messages
Fix re-distributing previously distributed invalidation messages during logical decoding. Commit 4909b38af0 introduced logic to distribute invalidation messages from catalog-modifying transactions to all concurrent in-progress transactions. However, since each transaction distributes not only its original invalidation messages but also previously distributed messages to other transactions, this leads to an exponential increase in allocation request size for invalidation messages, ultimately causing memory allocation failure. This commit fixes this issue by tracking distributed invalidation messages separately per decoded transaction and not redistributing these messages to other in-progress transactions. The maximum size of distributed invalidation messages that one transaction can store is limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the distributed invalidation messages exceeds this threshold, we invalidate all caches in locations where distributed invalidation messages need to be executed. Back-patch to all supported versions where we introduced the fix by commit 4909b38af0. Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. Additionally, it adds a new flag to the txn_flags field of ReorderBufferTXN to indicate distributed invalidation message overflow. This should not affect existing implementations, as it is unlikely that third-party extensions use unused bits in the txn_flags field. Bug: #18938 #18942 Author: vignesh C Reported-by: Duncan Sands Reported-by: John Hutchins Reported-by: Laurence Parry Reported-by: Max Madden Reported-by: Braulio Fdo Gonzalez Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c6...@deepbluecap.com Discussion: https://postgr.es/m/18942-0ab1e5ae15661...@postgresql.org Discussion: https://postgr.es/m/18938-57c9a1c463b68...@postgresql.org Discussion: https://postgr.es/m/cad1fgct2syrp_70rtuo56qtizyc+j3wjdtn2gto3vttqfpd...@mail.gmail.com Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuutnvtnjidmg0+-ffnrnqm6kd23qo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/983b3636259b1502121cbae99d8a2f0d0515d87d Modified Files -- .../expected/invalidation_distribution.out | 23 ++- .../specs/invalidation_distribution.spec | 11 ++ src/backend/replication/logical/reorderbuffer.c| 197 + src/backend/replication/logical/snapbuild.c| 12 +- src/include/replication/reorderbuffer.h| 32 +++- 5 files changed, 231 insertions(+), 44 deletions(-)
pgsql: Fix re-distributing previously distributed invalidation messages
Fix re-distributing previously distributed invalidation messages during logical decoding. Commit 4909b38af0 introduced logic to distribute invalidation messages from catalog-modifying transactions to all concurrent in-progress transactions. However, since each transaction distributes not only its original invalidation messages but also previously distributed messages to other transactions, this leads to an exponential increase in allocation request size for invalidation messages, ultimately causing memory allocation failure. This commit fixes this issue by tracking distributed invalidation messages separately per decoded transaction and not redistributing these messages to other in-progress transactions. The maximum size of distributed invalidation messages that one transaction can store is limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the distributed invalidation messages exceeds this threshold, we invalidate all caches in locations where distributed invalidation messages need to be executed. Back-patch to all supported versions where we introduced the fix by commit 4909b38af0. Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. Additionally, it adds a new flag to the txn_flags field of ReorderBufferTXN to indicate distributed invalidation message overflow. This should not affect existing implementations, as it is unlikely that third-party extensions use unused bits in the txn_flags field. Bug: #18938 #18942 Author: vignesh C Reported-by: Duncan Sands Reported-by: John Hutchins Reported-by: Laurence Parry Reported-by: Max Madden Reported-by: Braulio Fdo Gonzalez Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c6...@deepbluecap.com Discussion: https://postgr.es/m/18942-0ab1e5ae15661...@postgresql.org Discussion: https://postgr.es/m/18938-57c9a1c463b68...@postgresql.org Discussion: https://postgr.es/m/cad1fgct2syrp_70rtuo56qtizyc+j3wjdtn2gto3vttqfpd...@mail.gmail.com Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuutnvtnjidmg0+-ffnrnqm6kd23qo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b2ae077205e18ac3e6d7bc5f7a6fa25a39323ec0 Modified Files -- .../expected/invalidation_distribution.out | 23 ++- .../specs/invalidation_distribution.spec | 11 ++ src/backend/replication/logical/reorderbuffer.c| 195 + src/backend/replication/logical/snapbuild.c| 12 +- src/include/replication/reorderbuffer.h| 34 +++- 5 files changed, 230 insertions(+), 45 deletions(-)
pgsql: Fix re-distributing previously distributed invalidation messages
Fix re-distributing previously distributed invalidation messages during logical decoding. Commit 4909b38af0 introduced logic to distribute invalidation messages from catalog-modifying transactions to all concurrent in-progress transactions. However, since each transaction distributes not only its original invalidation messages but also previously distributed messages to other transactions, this leads to an exponential increase in allocation request size for invalidation messages, ultimately causing memory allocation failure. This commit fixes this issue by tracking distributed invalidation messages separately per decoded transaction and not redistributing these messages to other in-progress transactions. The maximum size of distributed invalidation messages that one transaction can store is limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the distributed invalidation messages exceeds this threshold, we invalidate all caches in locations where distributed invalidation messages need to be executed. Back-patch to all supported versions where we introduced the fix by commit 4909b38af0. Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. Additionally, it adds a new flag to the txn_flags field of ReorderBufferTXN to indicate distributed invalidation message overflow. This should not affect existing implementations, as it is unlikely that third-party extensions use unused bits in the txn_flags field. Bug: #18938 #18942 Author: vignesh C Reported-by: Duncan Sands Reported-by: John Hutchins Reported-by: Laurence Parry Reported-by: Max Madden Reported-by: Braulio Fdo Gonzalez Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c6...@deepbluecap.com Discussion: https://postgr.es/m/18942-0ab1e5ae15661...@postgresql.org Discussion: https://postgr.es/m/18938-57c9a1c463b68...@postgresql.org Discussion: https://postgr.es/m/cad1fgct2syrp_70rtuo56qtizyc+j3wjdtn2gto3vttqfpd...@mail.gmail.com Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuutnvtnjidmg0+-ffnrnqm6kd23qo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1230be12f086eec94324e2f03d8739dc779a3ff7 Modified Files -- .../expected/invalidation_distribution.out | 23 ++- .../specs/invalidation_distribution.spec | 11 ++ src/backend/replication/logical/reorderbuffer.c| 169 ++--- src/backend/replication/logical/snapbuild.c| 12 +- src/include/replication/reorderbuffer.h| 22 ++- 5 files changed, 207 insertions(+), 30 deletions(-)
pgsql: Fix re-distributing previously distributed invalidation messages
Fix re-distributing previously distributed invalidation messages during logical decoding. Commit 4909b38af0 introduced logic to distribute invalidation messages from catalog-modifying transactions to all concurrent in-progress transactions. However, since each transaction distributes not only its original invalidation messages but also previously distributed messages to other transactions, this leads to an exponential increase in allocation request size for invalidation messages, ultimately causing memory allocation failure. This commit fixes this issue by tracking distributed invalidation messages separately per decoded transaction and not redistributing these messages to other in-progress transactions. The maximum size of distributed invalidation messages that one transaction can store is limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the distributed invalidation messages exceeds this threshold, we invalidate all caches in locations where distributed invalidation messages need to be executed. Back-patch to all supported versions where we introduced the fix by commit 4909b38af0. Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. Additionally, it adds a new flag to the txn_flags field of ReorderBufferTXN to indicate distributed invalidation message overflow. This should not affect existing implementations, as it is unlikely that third-party extensions use unused bits in the txn_flags field. Bug: #18938 #18942 Author: vignesh C Reported-by: Duncan Sands Reported-by: John Hutchins Reported-by: Laurence Parry Reported-by: Max Madden Reported-by: Braulio Fdo Gonzalez Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c6...@deepbluecap.com Discussion: https://postgr.es/m/18942-0ab1e5ae15661...@postgresql.org Discussion: https://postgr.es/m/18938-57c9a1c463b68...@postgresql.org Discussion: https://postgr.es/m/cad1fgct2syrp_70rtuo56qtizyc+j3wjdtn2gto3vttqfpd...@mail.gmail.com Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuutnvtnjidmg0+-ffnrnqm6kd23qo...@mail.gmail.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fc0fb77c550fe8289d718c33c7aacf16023d9941 Modified Files -- .../expected/invalidation_distribution.out | 23 ++- .../specs/invalidation_distribution.spec | 11 ++ src/backend/replication/logical/reorderbuffer.c| 197 + src/backend/replication/logical/snapbuild.c| 12 +- src/include/replication/reorderbuffer.h| 32 +++- 5 files changed, 231 insertions(+), 44 deletions(-)
pgsql: Fix re-distributing previously distributed invalidation messages
Fix re-distributing previously distributed invalidation messages during logical decoding. Commit 4909b38af0 introduced logic to distribute invalidation messages from catalog-modifying transactions to all concurrent in-progress transactions. However, since each transaction distributes not only its original invalidation messages but also previously distributed messages to other transactions, this leads to an exponential increase in allocation request size for invalidation messages, ultimately causing memory allocation failure. This commit fixes this issue by tracking distributed invalidation messages separately per decoded transaction and not redistributing these messages to other in-progress transactions. The maximum size of distributed invalidation messages that one transaction can store is limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the distributed invalidation messages exceeds this threshold, we invalidate all caches in locations where distributed invalidation messages need to be executed. Back-patch to all supported versions where we introduced the fix by commit 4909b38af0. Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. Additionally, it adds a new flag to the txn_flags field of ReorderBufferTXN to indicate distributed invalidation message overflow. This should not affect existing implementations, as it is unlikely that third-party extensions use unused bits in the txn_flags field. Bug: #18938 #18942 Author: vignesh C Reported-by: Duncan Sands Reported-by: John Hutchins Reported-by: Laurence Parry Reported-by: Max Madden Reported-by: Braulio Fdo Gonzalez Reviewed-by: Masahiko Sawada Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c6...@deepbluecap.com Discussion: https://postgr.es/m/18942-0ab1e5ae15661...@postgresql.org Discussion: https://postgr.es/m/18938-57c9a1c463b68...@postgresql.org Discussion: https://postgr.es/m/cad1fgct2syrp_70rtuo56qtizyc+j3wjdtn2gto3vttqfpd...@mail.gmail.com Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuutnvtnjidmg0+-ffnrnqm6kd23qo...@mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d87d07b7ad3b782cb74566cd771ecdb2823adf6a Modified Files -- .../expected/invalidation_distribution.out | 23 ++- .../specs/invalidation_distribution.spec | 11 ++ src/backend/replication/logical/reorderbuffer.c| 196 + src/backend/replication/logical/snapbuild.c| 12 +- src/include/replication/reorderbuffer.h| 16 ++ 5 files changed, 222 insertions(+), 36 deletions(-)
