pgsql: Fix bugs in libpq's management of GSS encryption state.
Fix bugs in libpq's management of GSS encryption state. GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/25fe5ac45a736e50d2b85280a3cb0ce169f583f3 Modified Files -- src/interfaces/libpq/fe-connect.c | 37 + 1 file changed, 9 insertions(+), 28 deletions(-)
pgsql: Improvements to psql \dAo and \dAp commands
Improvements to psql \dAo and \dAp commands * Strategy number and purpose are essential information for opfamily operator. So, show those columns in non-verbose output. * "Left/right arg type" \dAp column names are confusing, because those type don't necessary match to function arguments. Rename them to "Registered left/right type". * Replace manual assembling of operator/procedure names with casts to regoperator/regprocedure. * Add schema-qualification for pg_catalog functions and tables. Reported-by: Peter Eisentraut, Tom Lane Reviewed-by: Tom Lane Discussion: https://postgr.es/m/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ae290059e1aa5bc2272a0345184bcf05407f69a4 Modified Files -- src/bin/psql/command.c | 2 +- src/bin/psql/describe.c| 93 ++-- src/bin/psql/describe.h| 2 +- src/test/regress/expected/psql.out | 98 +++--- src/test/regress/sql/psql.sql | 2 +- 5 files changed, 98 insertions(+), 99 deletions(-)
pgsql: Improvements to psql \dAo and \dAp commands
Improvements to psql \dAo and \dAp commands * Strategy number and purpose are essential information for opfamily operator. So, show those columns in non-verbose output. * "Left/right arg type" \dAp column names are confusing, because those type don't necessary match to function arguments. Rename them to "Registered left/right type". * Replace manual assembling of operator/procedure names with casts to regoperator/regprocedure. * Add schema-qualification for pg_catalog functions and tables. Reported-by: Peter Eisentraut, Tom Lane Reviewed-by: Tom Lane Discussion: https://postgr.es/m/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8d2ed66e4107ef27d05aef682c68af5952af7690 Modified Files -- src/bin/psql/command.c | 2 +- src/bin/psql/describe.c| 93 ++-- src/bin/psql/describe.h| 2 +- src/test/regress/expected/psql.out | 98 +++--- src/test/regress/sql/psql.sql | 2 +- 5 files changed, 98 insertions(+), 99 deletions(-)
pgsql: Fix bugs in libpq's management of GSS encryption state.
Fix bugs in libpq's management of GSS encryption state. GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota@gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e6f134a9a8db52cbd2818ce8a60b9e5cdadfc8f Modified Files -- src/interfaces/libpq/fe-connect.c | 37 + 1 file changed, 9 insertions(+), 28 deletions(-)
pgsql: Fix bugs in libpq's management of GSS encryption state.
Fix bugs in libpq's management of GSS encryption state. GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota@gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e8b22a8a2b65a678d38a120bf7b8cadc144cad17 Modified Files -- src/interfaces/libpq/fe-connect.c | 37 + 1 file changed, 9 insertions(+), 28 deletions(-)
Re: pgsql: Improvements to psql \dAo and \dAp commands
On Mon, Jul 13, 2020 at 6:57 PM Alexander Korotkov wrote: > Improvements to psql \dAo and \dAp commands Oops, I've just pushed the commit with timestamp too far in the past. Sorry for that. -- Regards, Alexander Korotkov
pgsql: Fix uninitialized value in segno calculation
Fix uninitialized value in segno calculation Remove previous hack in KeepLogSeg that added a case to deal with a (badly represented) invalid segment number. This was added for the sake of GetWALAvailability. But it's not needed if in that function we initialize the segment number to be retreated to the currently being written segment, so do that instead. Per valgrind-running buildfarm member skink, and some sparc64 animals. Discussion: https://postgr.es/m/1724648.1594230...@sss.pgh.pa.us Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/794e8e32bb5ae1b38a90cbae2a88895633797599 Modified Files -- src/backend/access/transam/xlog.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-)
pgsql: Fix uninitialized value in segno calculation
Fix uninitialized value in segno calculation Remove previous hack in KeepLogSeg that added a case to deal with a (badly represented) invalid segment number. This was added for the sake of GetWALAvailability. But it's not needed if in that function we initialize the segment number to be retreated to the currently being written segment, so do that instead. Per valgrind-running buildfarm member skink, and some sparc64 animals. Discussion: https://postgr.es/m/1724648.1594230...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b5b4c0fef9fb905d98f93c1f455397449c6e63a8 Modified Files -- src/backend/access/transam/xlog.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-)
Re: pgsql: Improvements to psql \dAo and \dAp commands
Alexander Korotkov writes: > On Mon, Jul 13, 2020 at 6:57 PM Alexander Korotkov > wrote: >> Improvements to psql \dAo and \dAp commands > Oops, I've just pushed the commit with timestamp too far in the past. > Sorry for that. Some committers use workflows where the author-date is regularly well in the past. Because of that, git_changelog and other tools tend to look at the committer-date instead. Don't sweat about it. regards, tom lane
Re: pgsql: Improvements to psql \dAo and \dAp commands
On Mon, Jul 13, 2020 at 10:39 PM Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Jul 13, 2020 at 6:57 PM Alexander Korotkov > > wrote: > >> Improvements to psql \dAo and \dAp commands > > > Oops, I've just pushed the commit with timestamp too far in the past. > > Sorry for that. > > Some committers use workflows where the author-date is regularly > well in the past. Because of that, git_changelog and other tools > tend to look at the committer-date instead. Don't sweat about it. Got it, thanks! -- Regards, Alexander Korotkov
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc6bb09949c821fc0db520e75b795ff226aba60c Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3753df8f8ae8e16bf81bc809514982b35a94f4a1 Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0734dbc45034540fec1d98b15c9f173ad1d4af02 Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6443cd2e242175890ede181b96bf47b0d9b259ce Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/80d8f6d1d6338c335c84048e65e1203fada863b2 Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a742ecf9c63d454ccb107a357288c8ec1444ca12 Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Cope with lateral references in the quals of a subquery RTE.
Cope with lateral references in the quals of a subquery RTE. The qual pushdown logic assumed that all Vars in a restriction clause must be Vars referencing subquery outputs; but since we introduced LATERAL, it's possible for such a Var to be a lateral reference instead. This led to an assertion failure in debug builds. In a non-debug build, there might be no ill effects (if qual_is_pushdown_safe decided the qual was unsafe anyway), or we could get failures later due to construction of an invalid plan. I've not gone to much length to characterize the possible failures, but at least segfaults in the executor have been observed. Given that this has been busted since 9.3 and it took this long for anybody to notice, I judge that the case isn't worth going to great lengths to optimize. Hence, fix by just teaching qual_is_pushdown_safe that such quals are unsafe to push down, matching the previous behavior when it accidentally didn't fail. Per report from Tom Ellis. Back-patch to all supported branches. Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d3b642ad99e958475bab4592db0341badfacee56 Modified Files -- src/backend/optimizer/path/allpaths.c | 20 +++-- src/test/regress/expected/subselect.out | 53 + src/test/regress/sql/subselect.sql | 26 3 files changed, 96 insertions(+), 3 deletions(-)
pgsql: Fix comments related to table AMs
Fix comments related to table AMs Incorrect function names were referenced. As this fixes some portions of tableam.h, that is mentioned in the docs as something to look at when implementing a table AM, backpatch down to 12 where this has been introduced. Author: Hironobu Suzuki Discussion: https://postgr.es/m/8fe6d672-28dd-3f1d-7aed-ac2f6d599...@interdb.jp Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/330410ecadfb406c99d08c24efde651e18f653bf Modified Files -- src/backend/access/heap/heapam.c | 6 +++--- src/include/access/tableam.h | 21 +++-- 2 files changed, 14 insertions(+), 13 deletions(-)
pgsql: Fix comments related to table AMs
Fix comments related to table AMs Incorrect function names were referenced. As this fixes some portions of tableam.h, that is mentioned in the docs as something to look at when implementing a table AM, backpatch down to 12 where this has been introduced. Author: Hironobu Suzuki Discussion: https://postgr.es/m/8fe6d672-28dd-3f1d-7aed-ac2f6d599...@interdb.jp Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9678c08184a82deafac9297b9af0fc5cb07ab347 Modified Files -- src/backend/access/heap/heapam.c | 6 +++--- src/include/access/tableam.h | 21 +++-- 2 files changed, 14 insertions(+), 13 deletions(-)
pgsql: Fix comments related to table AMs
Fix comments related to table AMs Incorrect function names were referenced. As this fixes some portions of tableam.h, that is mentioned in the docs as something to look at when implementing a table AM, backpatch down to 12 where this has been introduced. Author: Hironobu Suzuki Discussion: https://postgr.es/m/8fe6d672-28dd-3f1d-7aed-ac2f6d599...@interdb.jp Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9168793d7275b4b318c153d607fba55d14098c19 Modified Files -- src/backend/access/heap/heapam.c | 6 +++--- src/include/access/tableam.h | 21 +++-- 2 files changed, 14 insertions(+), 13 deletions(-)
pgsql: Fix some header identifications
Fix some header identifications The following header files missed the shot: - jsonfuncs.h, as of ce0425b. - jsonapi.h, as of beb4699. - llvmjit_emit.h as of 7ec0d80. - partdesc.h, as of 1bb5e78. Author: Jesse Zhang Discussion: https://postgr.es/m/cagf+fx4-8xuleoz09de2dzgjt+q8vj--rqftpvcfwc+a4fc...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b8401c32bacd0869bd00bc71fd64f1d6071bcd6a Modified Files -- src/include/common/jsonapi.h| 2 +- src/include/jit/llvmjit_emit.h | 2 +- src/include/partitioning/partdesc.h | 2 +- src/include/utils/jsonfuncs.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b827304291aff8019cdd0cee68219fe43f064380 Modified Files -- src/backend/commands/tablecmds.c | 155 ++ src/test/regress/expected/alter_table.out | 22 - src/test/regress/sql/alter_table.sql | 22 + 3 files changed, 93 insertions(+), 106 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f1fcf2d3b2e00b3d7ad3e0d2b1d26b77f5a48413 Modified Files -- src/backend/commands/tablecmds.c | 155 ++ src/test/regress/expected/alter_table.out | 22 - src/test/regress/sql/alter_table.sql | 22 + 3 files changed, 93 insertions(+), 106 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1231a0b0ea66df231875a7470a74ac060f5b9b97 Modified Files -- src/backend/commands/tablecmds.c | 155 ++ src/test/regress/expected/alter_table.out | 22 - src/test/regress/sql/alter_table.sql | 22 + 3 files changed, 94 insertions(+), 105 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d2761b680a9052b9d62912cfcc36c154f28517ce Modified Files -- src/backend/commands/tablecmds.c | 162 ++ src/test/regress/expected/alter_table.out | 22 +++- src/test/regress/sql/alter_table.sql | 22 3 files changed, 95 insertions(+), 111 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4e02f88a4eedd2f9808c16d6d7b50c3a78af2d39 Modified Files -- src/backend/commands/tablecmds.c | 162 ++ src/test/regress/expected/alter_table.out | 22 +++- src/test/regress/sql/alter_table.sql | 22 3 files changed, 95 insertions(+), 111 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c732df133a3d4ad32b9fb35f2f1b15cb08ac6b3a Modified Files -- src/backend/commands/tablecmds.c | 159 ++ src/test/regress/expected/alter_table.out | 22 - src/test/regress/sql/alter_table.sql | 22 + 3 files changed, 95 insertions(+), 108 deletions(-)
pgsql: Fix timing issue with ALTER TABLE's validate constraint
Fix timing issue with ALTER TABLE's validate constraint An ALTER TABLE to validate a foreign key in which another subcommand already caused a pending table rewrite could fail due to ALTER TABLE attempting to validate the foreign key before the actual table rewrite takes place. This situation could result in an error such as: ERROR: could not read block 0 in file "base/n/n": read only 0 of 8192 bytes The failure here was due to the SPI call which validates the foreign key trying to access an index which is yet to be rebuilt. Similarly, we also incorrectly tried to validate CHECK constraints before the heap had been rewritten. The fix for both is to delay constraint validation until phase 3, after the table has been rewritten. For CHECK constraints this means a slight behavioral change. Previously ALTER TABLE VALIDATE CONSTRAINT on inheritance tables would be validated from the bottom up. This was different from the order of evaluation when a new CHECK constraint was added. The changes made here aligns the VALIDATE CONSTRAINT evaluation order for inheritance tables to be the same as ADD CONSTRAINT, which is generally top-down. Reported-by: Nazli Ugur Koyluoglu, using SQLancer Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com Backpatch-through: 9.5 (all supported versions) Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e20003fa0f8d35fa03bc60273e1cee4558f19e41 Modified Files -- src/backend/commands/tablecmds.c | 159 ++ src/test/regress/expected/alter_table.out | 22 - src/test/regress/sql/alter_table.sql | 22 + 3 files changed, 95 insertions(+), 108 deletions(-)
pgsql: Add comment to explain an unused function parameter
Add comment to explain an unused function parameter Removing the unused 'miinfo' parameter has been raised a couple of times now. It was decided in the 2nd discussion below that we're going to leave it alone. It seems like it might be useful to add a comment to mention this fact so that nobody wastes any time in the future proposing its removal again. Discussion: https://postgr.es/m/CAApHDvpCf-qR5HC1rXskUM4ToV+3YDb4-n1meY=vpahsrs_...@mail.gmail.com Discussion: https://postgr.es/m/CAE9k0P%3DFvcDswnSVtRpSyZMpcAWC%3DGp%3DifZ0HdfPaRQ%3D__LBtw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/101f903e51f52bf595cd8177d2e0bc6fe9000762 Modified Files -- src/backend/commands/copy.c | 3 +++ 1 file changed, 3 insertions(+)
