pgsql: Ensure all perl test modules are installed
Ensure all perl test modules are installed PostgreSQL::Test::Cluster and ::Utils were not being installed. This is very hard to notice, as it only seems to affect external modules that want to run tests from 15 back in earlier versions. Oversight in b235d41d9646. This applies only to branches 14 and back, because 15 had already been made correct in commit b3b4d8e68ae8. Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dd82638734ed37fc0fa7a56050d636890ed8877c Modified Files -- src/test/perl/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Ensure all perl test modules are installed
Ensure all perl test modules are installed PostgreSQL::Test::Cluster and ::Utils were not being installed. This is very hard to notice, as it only seems to affect external modules that want to run tests from 15 back in earlier versions. Oversight in b235d41d9646. This applies only to branches 14 and back, because 15 had already been made correct in commit b3b4d8e68ae8. Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fa5c13178f26ed21a30c7c1ae537ede4962c71a1 Modified Files -- src/test/perl/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Ensure all perl test modules are installed
Ensure all perl test modules are installed PostgreSQL::Test::Cluster and ::Utils were not being installed. This is very hard to notice, as it only seems to affect external modules that want to run tests from 15 back in earlier versions. Oversight in b235d41d9646. This applies only to branches 14 and back, because 15 had already been made correct in commit b3b4d8e68ae8. Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8bf4705272ef7c8bb39d8f37de069b5a33a2112e Modified Files -- src/test/perl/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Ensure all perl test modules are installed
Ensure all perl test modules are installed PostgreSQL::Test::Cluster and ::Utils were not being installed. This is very hard to notice, as it only seems to affect external modules that want to run tests from 15 back in earlier versions. Oversight in b235d41d9646. This applies only to branches 14 and back, because 15 had already been made correct in commit b3b4d8e68ae8. Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4f6d1cfd6b6f0707e4f4c3479261845263256f77 Modified Files -- src/test/perl/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Ensure all perl test modules are installed
Ensure all perl test modules are installed PostgreSQL::Test::Cluster and ::Utils were not being installed. This is very hard to notice, as it only seems to affect external modules that want to run tests from 15 back in earlier versions. Oversight in b235d41d9646. This applies only to branches 14 and back, because 15 had already been made correct in commit b3b4d8e68ae8. Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33d979aeecfbf0bfe3c93eb0ffecab870e909192 Modified Files -- src/test/perl/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: C comment: explain procArray->pgprocnos[]
C comment: explain procArray->pgprocnos[] Reported-by: Aleksander Alekseev Discussion: https://postgr.es/m/CAJ7c6TOs9Dh3KNR2kiQJ3Ow0=tbucl_57dabm--2p8w5x_8...@mail.gmail.com Author: Aleksander Alekseev Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/434c6cdf0cc9b4ee0d3c7fd2351d751fecdef8dc Modified Files -- src/include/storage/proc.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Doc: add entry for pg_get_partkeydef().
Doc: add entry for pg_get_partkeydef(). Other pg_get_XXXdef() functions are documented, so it seems reasonable to include this as well. Ian Barwick Discussion: https://postgr.es/m/CAB8KJ=hb2QZXdgyrrRjPCw++DsrRcui4fKArWabQ+oij+2x=_...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/422f86a82edcc53076d120cbc9a584e40be30013 Modified Files -- doc/src/sgml/func.sgml | 17 + 1 file changed, 17 insertions(+)
pgsql: Tag refs/tags/REL_15_0 was created
Tag refs/tags/REL_15_0 was created.
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b8f2687fdc410371bbfa579ab7c4fd4b7a5ed1cb Modified Files -- src/backend/rewrite/rewriteHandler.c | 87 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 98 insertions(+), 28 deletions(-)
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/07ce6769824c4081208122ae3c1b38812e4715ed Modified Files -- src/backend/rewrite/rewriteHandler.c | 87 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 98 insertions(+), 28 deletions(-)
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/abc510fa2a34eba00406e9ce330b77e1d9c4ccdf Modified Files -- src/backend/rewrite/rewriteHandler.c | 84 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 97 insertions(+), 26 deletions(-)
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/23e2a06acf0435c1337e0a1e1d473e35eced7d6d Modified Files -- src/backend/rewrite/rewriteHandler.c | 84 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 97 insertions(+), 26 deletions(-)
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/21e042b0bd47d8564f7178f72114d707cb1ceba8 Modified Files -- src/backend/rewrite/rewriteHandler.c | 84 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 97 insertions(+), 26 deletions(-)
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3162bd95cad3bf9ad89b9c7c8e50716cb513d46f Modified Files -- src/backend/rewrite/rewriteHandler.c | 87 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 98 insertions(+), 28 deletions(-)
pgsql: Yet further fixes for multi-row VALUES lists for updatable views
Yet further fixes for multi-row VALUES lists for updatable views. DEFAULT markers appearing in an INSERT on an updatable view could be mis-processed if they were in a multi-row VALUES clause. This would lead to strange errors such as "cache lookup failed for type ", or in older branches even to crashes. The cause is that commit 41531e42d tried to re-use rewriteValuesRTE() to remove any SetToDefault nodes (that hadn't previously been replaced by the view's own default values) appearing in "product" queries, that is DO ALSO queries. That's fundamentally wrong because the DO ALSO queries might not even be INSERTs; and even if they are, their targetlists don't necessarily match the view's column list, so that almost all the logic in rewriteValuesRTE() is inapplicable. What we want is a narrow focus on replacing any such nodes with NULL constants. (That is, in this context we are interpreting the defaults as being strictly those of the view itself; and we already replaced any that aren't NULL.) We could add still more !force_nulls tests to further lobotomize rewriteValuesRTE(); but it seems cleaner to split out this case to a new function, restoring rewriteValuesRTE() to the charter it had before. Per bug #17633 from jiye_sw. Patch by me, but thanks to Richard Guo and Japin Li for initial investigation. Back-patch to all supported branches, as the previous fix was. Discussion: https://postgr.es/m/17633-98cc85e1fa91e...@postgresql.org Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/addde9bc6caf2563f01ecea1ff01e22c328da1ad Modified Files -- src/backend/rewrite/rewriteHandler.c | 84 ++- src/test/regress/expected/updatable_views.out | 22 +++ src/test/regress/sql/updatable_views.sql | 17 ++ 3 files changed, 97 insertions(+), 26 deletions(-)
Re: pgsql: Add support for COPY TO callback functions
Hi, On 2022-10-11 02:47:56 +, Michael Paquier wrote: > Add support for COPY TO callback functions > > This is useful as a way for extensions to process COPY TO rows in the > way they see fit (say auditing, analytics, backend, etc.) without the > need to invoke an external process running as the OS user running the > backend through PROGRAM that requires superuser rights. COPY FROM > already provides a similar callback for logical replication. For COPY > TO, the callback is triggered when we are ready to send a row in > CopySendEndOfRow(), which is the same code path as when sending a row > to a frontend or a pipe/file. > > A small test module, test_copy_callbacks, is added to provide some > coverage for this facility. New warning with msvc 2022: C:\dev\postgres-meson\src\test\modules\test_copy_callbacks\test_copy_callbacks.c(40,73): warning C4047: 'function': 'bool' differs in levels of indirection from 'void *' [C:\dev\postgres-meson\build-msbuild-2022\src\test\modules\test_copy_callbacks\7d667bc@@test_copy_callbacks@sha.vcxproj] C:\dev\postgres-meson\src\test\modules\test_copy_callbacks\test_copy_callbacks.c(40,69): warning C4024: 'BeginCopyTo': different types for formal and actual parameter 6 [C:\dev\postgres-meson\build-msbuild-2022\src\test\modules\test_copy_callbacks\7d667bc@@test_copy_callbacks@sha.vcxproj] Looks quite justified. Passing NULL to bool is_program isn't right. Greetings, Andres Freund
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b10546ecf8266d2b368b98ccd491eeae5160e316 Modified Files -- src/backend/storage/ipc/pmsignal.c | 56 ++ 1 file changed, 44 insertions(+), 12 deletions(-)
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8f98352b5ed9f1c32ad9277a83d4adf5e1055a15 Modified Files -- src/backend/storage/ipc/pmsignal.c | 56 ++ 1 file changed, 44 insertions(+), 12 deletions(-)
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6c1de98bad93b6f12b5002b40c4a0cbd3adeafdb Modified Files -- src/backend/storage/ipc/pmsignal.c | 55 +- 1 file changed, 43 insertions(+), 12 deletions(-)
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7442701374a448663061c493b40926c4e8d68838 Modified Files -- src/backend/storage/ipc/pmsignal.c | 56 ++ 1 file changed, 44 insertions(+), 12 deletions(-)
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e7b4ff327c4d5cc8ff3eaebff9c79c28232cabdd Modified Files -- src/backend/storage/ipc/pmsignal.c | 56 ++ 1 file changed, 44 insertions(+), 12 deletions(-)
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/18a4a620e2de0e25a15303a8f78ff415950a14ef Modified Files -- src/backend/storage/ipc/pmsignal.c | 56 ++ 1 file changed, 44 insertions(+), 12 deletions(-)
pgsql: Harden pmsignal.c against clobbered shared memory.
Harden pmsignal.c against clobbered shared memory. The postmaster is not supposed to do anything that depends fundamentally on shared memory contents, because that creates the risk that a backend crash that trashes shared memory will take the postmaster down with it, preventing automatic recovery. In commit 969d7cd43 I lost sight of this principle and coded AssignPostmasterChildSlot() in such a way that it could fail or even crash if the shared PMSignalState structure became corrupted. Remarkably, we've not seen field reports of such crashes; but I managed to induce one while testing the recent changes around palloc chunk headers. To fix, make a semi-duplicative state array inside the postmaster so that we need consult only local state while choosing a "child slot" for a new backend. Ensure that other postmaster-executed routines in pmsignal.c don't have critical dependencies on the shared state, either. Corruption of PMSignalState might now lead ReleasePostmasterChildSlot() to conclude that backend X failed, when actually backend Y was the one that trashed things. But that doesn't matter, because we'll force a cluster-wide reset regardless. Back-patch to all supported branches, since this is an old bug. Discussion: https://postgr.es/m/3436789.1665187...@sss.pgh.pa.us Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ab35b9dd79b36286553c2db97278cc2a101d66e0 Modified Files -- src/backend/storage/ipc/pmsignal.c | 55 +- 1 file changed, 43 insertions(+), 12 deletions(-)
pgsql: Fix compilation warning in test_copy_callbacks
Fix compilation warning in test_copy_callbacks A passed-in parameter value was incorrect, for a warning coming from MSVC. Oversight in 9fcdf2c. Reported-by: Andres Freund Discussion: https://postgr.es/m/20221011224221.dvg5q7e7vhjdt...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/94fd253d561bcc1db067d04f75fc1f34c3b9962f Modified Files -- src/test/modules/test_copy_callbacks/test_copy_callbacks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: Add support for COPY TO callback functions
On Tue, Oct 11, 2022 at 03:42:21PM -0700, Andres Freund wrote: > Looks quite justified. Passing NULL to bool is_program isn't right. Justified it is. Thanks! -- Michael signature.asc Description: PGP signature
pgsql: Simplify some maths in xlogreader.c
Simplify some maths in xlogreader.c An LSN was calculated from a segment number, a segment size and a position offset, matching exactly the LSN given by the caller of XLogReaderValidatePageHeader(). This change removes the extra LSN calculation, relying only on the LSN given by the function caller instead. Author: Bharath Rupireddy Reviewed-by: Richard Guo, Álvaro Herrera, Kyotaro Horiguchi Discussion: https://postgr.es/m/CALj2ACXuh4Ms9j9sxMYdtHEe=5sfcyrs-gahyadu_a_g71k...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a1176c67c42cf687675be762ebb6075e092d3d0a Modified Files -- src/backend/access/transam/xlogreader.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
pgsql: Fix shadow variable in postgres.c
Fix shadow variable in postgres.c -Wshadow=compatible-local is added by default since 0fe954c, and this warning was detected under -DWRITE_READ_PARSE_PLAN_TREES. Reviewed-by: David Rowley Discussion: https://postgr.es/m/y0ya5sh0qiao9...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4574eb9d38c69f4c90b5468f740ff22519752066 Modified Files -- src/backend/tcop/postgres.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove Abs()
Remove Abs() All callers have been replaced by standard C library functions. Reviewed-by: Zhang Mingli Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/4beb42b5-216b-bce8-d452-d924d5794c63%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a699b7a7aa9f34c19aa7632b3f037f24c8ee7720 Modified Files -- src/include/c.h | 6 -- 1 file changed, 6 deletions(-)
pgsql: Add meson.build to version_stamp.pl
Add meson.build to version_stamp.pl Author: Dagfinn Ilmari Mannsåker Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/flat/7567dd2d-5e28-c135-79ff-270d7ed83490%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/38409787dc071d6af947a5eb4819ba97a24431f7 Modified Files -- src/tools/version_stamp.pl | 3 +++ 1 file changed, 3 insertions(+)
