pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e626b6b9d318b147f2fd7a97e2117fcb90f6ee77 Modified Files -- contrib/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/87be73e3ff1cd2e4474f8305a214a9d61535d2fb Modified Files -- src/bin/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd30f51c0ec97207ac9baf68d03fd4e851f9777f Modified Files -- src/bin/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/45d74631b3973390ff02cd765a674e6322e1c8db Modified Files -- src/bin/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b94f7b5350e97ef0587c0c64aed6eb940d964c06 Modified Files -- src/bin/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/30f480141b646b7ebb86ba1bd880ffa0df503db1 Modified Files -- src/bin/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: pg_upgrade: issue helpful error message for use on standbys
pg_upgrade: issue helpful error message for use on standbys Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/capdie1xycow-reljrhj9dqrmu-ppnq0chuuevvdxhdjgrd5...@mail.gmail.com Backpatch-through: 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a49cf6ef3d0c0e90b0c69d34c829488d3fbe7638 Modified Files -- contrib/pg_upgrade/controldata.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)
pgsql: Fix configure's snprintf test so it exposes HP-UX bug.
Fix configure's snprintf test so it exposes HP-UX bug. Since commit e1d19c902, buildfarm member gharial has been failing with symptoms indicating that snprintf sometimes returns -1 for buffer overrun, even though it passes the added configure check. Some google research suggests that this happens only in limited cases, such as when the overrun happens partway through a %d item. Adjust the configure check to exercise it that way. Since I'm now feeling more paranoid than I was before, also make the test explicitly verify that the buffer doesn't get physically overrun. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9bed827b18cc4f27fb7cd7c02ad301519eca6d29 Modified Files -- config/c-library.m4 | 11 --- configure | 9 ++--- 2 files changed, 14 insertions(+), 6 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3cf3a65cb7da973dd761c6da579cdf7bceb38947 Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- src/test/regress/expected/subselect.out | 17 + src/test/regress/sql/subselect.sql | 16 3 files changed, 57 insertions(+), 2 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/520acab171244b55d816c70b9a89280b09937925 Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- src/test/regress/expected/subselect.out | 17 + src/test/regress/sql/subselect.sql | 16 3 files changed, 57 insertions(+), 2 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6302fe6b28e24e87d78e457e85362dc2fa9ca119 Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- src/test/regress/expected/subselect.out | 17 + src/test/regress/sql/subselect.sql | 16 3 files changed, 57 insertions(+), 2 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d2ecc27c374ad04b06fc62f365ff9445854153fd Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- src/test/regress/expected/subselect.out | 17 + src/test/regress/sql/subselect.sql | 16 3 files changed, 57 insertions(+), 2 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/807c1c5550643379ac1b65aca55ce1aedb0c2902 Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d31ebbff5b2bbe9dfe3fb130448581a4da388031 Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- src/test/regress/expected/subselect.out | 17 + src/test/regress/sql/subselect.sql | 16 3 files changed, 57 insertions(+), 2 deletions(-)
pgsql: Set scan direction appropriately for SubPlans (bug #15336)
Set scan direction appropriately for SubPlans (bug #15336) When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/67b161eae32b0e900f74a2fe0b3f01667ca70850 Modified Files -- src/backend/executor/nodeSubplan.c | 26 -- src/test/regress/expected/subselect.out | 17 + src/test/regress/sql/subselect.sql | 16 3 files changed, 57 insertions(+), 2 deletions(-)
pgsql: InsertPgAttributeTuple() to set attcacheoff
InsertPgAttributeTuple() to set attcacheoff InsertPgAttributeTuple() is the interface between in-memory tuple descriptors and on-disk pg_attribute, so it makes sense to give it the job of resetting attcacheoff. This avoids having all the callers having to do so. Reviewed-by: Tom Lane Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e4597ee65d683e11a57a4b7f597807ebf44b6cf1 Modified Files -- src/backend/catalog/heap.c | 9 - src/backend/catalog/index.c | 5 - src/backend/commands/tablecmds.c | 1 - 3 files changed, 4 insertions(+), 11 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a4fdcceaba1fa5c70dde920b5a22b3896c55efd1 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b2171d472dc77d176bc71a584ec3a2b48faa9d21 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d73093c4ffefebadd25ea855bd8745f4fcb4462a Modified Files -- src/bin/pg_dump/parallel.c | 2 +- src/bin/pg_dump/pg_backup_archiver.c | 12 +++- src/bin/pg_dump/pg_dump.c| 4 +--- src/bin/scripts/common.c | 3 +-- src/bin/scripts/vacuumdb.c | 3 +-- src/fe_utils/string_utils.c | 9 - src/include/fe_utils/string_utils.h | 3 +-- 7 files changed, 12 insertions(+), 24 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3998dfe1b5107e6c39e9c90ca856144e1094385a Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/72329ba03b601bcd0cfe1349a9acdd251972cbd0 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/05aeeb5e2803ebe537516774f766792c109eaac5 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER
Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6771c932cf5a8bbb8219461066987ad3b11688ff Modified Files -- src/bin/pg_dump/parallel.c | 2 +- src/bin/pg_dump/pg_backup_archiver.c | 12 +++- src/bin/pg_dump/pg_dump.c| 4 +--- src/bin/scripts/common.c | 3 +-- src/bin/scripts/vacuumdb.c | 3 +-- src/fe_utils/string_utils.c | 9 - src/include/fe_utils/string_utils.h | 3 +-- 7 files changed, 12 insertions(+), 24 deletions(-)
