pgsql: Avoid invalid array reference in transformAlterTableStmt().
Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb574...@postgresql.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0795da86954451709acf19e1ac9512d9fb384689 Modified Files -- src/backend/parser/parse_utilcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Avoid invalid array reference in transformAlterTableStmt().
Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb574...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/36d4efe779bfc7190ea1c1cf8deb0d945b726663 Modified Files -- src/backend/parser/parse_utilcmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Avoid invalid array reference in transformAlterTableStmt().
Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb574...@postgresql.org Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/69cefb3fb8377992bd2ad0dce1b33570b3e5244a Modified Files -- src/backend/parser/parse_utilcmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Avoid invalid array reference in transformAlterTableStmt().
Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb574...@postgresql.org Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2ceec5bb396bceeb40e7ac7089041c856e9c21e5 Modified Files -- src/backend/parser/parse_utilcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Avoid invalid array reference in transformAlterTableStmt().
Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb574...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e805735a83f7bb5bfe773b9690f96a52ba2b84b2 Modified Files -- src/backend/parser/parse_utilcmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Avoid invalid array reference in transformAlterTableStmt().
Avoid invalid array reference in transformAlterTableStmt(). Don't try to look at the attidentity field of system attributes, because they're not there in the TupleDescAttr array. Sometimes this is harmless because we accidentally pick up a zero, but otherwise we'll report "no owned sequence found" from an attempt to alter a system attribute. (It seems possible that a SIGSEGV could occur, too, though I've not seen it in testing.) It's not in this function's charter to complain that you can't alter a system column, so instead just hard-wire an assumption that system attributes aren't identities. I didn't bother with a regression test because the appearance of the bug is very erratic. Per bug #17465 from Roman Zharkov. Back-patch to all supported branches. (There's not actually a live bug before v12, because before that get_attidentity() did the right thing anyway. But for consistency I changed the test in the older branches too.) Discussion: https://postgr.es/m/17465-f2a554a6cb574...@postgresql.org Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20af44693c45768d466a056566361fac0dd185e1 Modified Files -- src/backend/parser/parse_utilcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Add missing error handling in pg_md5_hash().
Add missing error handling in pg_md5_hash(). It failed to provide an error string as expected for the admittedly-unlikely case of OOM in pg_cryptohash_create(). Also, make it initialize *errstr to NULL for success, as pg_md5_binary() does. Also add missing comments. Readers should not have to reverse-engineer the API spec for a publicly visible routine. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/587de223f03e6086d511dab16b17406eb21277ce Modified Files -- src/common/md5_common.c | 13 + 1 file changed, 13 insertions(+)
pgsql: Fix the check to limit sync workers.
Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e79...@enterprisedb.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be46985bed8a071a4f7d6016f955f3a71f3b04ca Modified Files -- src/backend/replication/logical/launcher.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix the check to limit sync workers.
Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e79...@enterprisedb.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c9dea58e270236a8d256a686f71f6bab960f0b80 Modified Files -- src/backend/replication/logical/launcher.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix the check to limit sync workers.
Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e79...@enterprisedb.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a90de822e4834f046b6c640e8a0ea40cd4ddde25 Modified Files -- src/backend/replication/logical/launcher.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix the check to limit sync workers.
Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e79...@enterprisedb.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/59348fbdeb7b4e39c992779232ab47069d272135 Modified Files -- src/backend/replication/logical/launcher.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix the check to limit sync workers.
Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e79...@enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd4ab6fd6528e160571986fa8817cee9f2645aa8 Modified Files -- src/backend/replication/logical/launcher.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix the check to limit sync workers.
Fix the check to limit sync workers. We don't allow to invoke more sync workers once we have reached the sync worker limit per subscription. But the check to enforce this also doesn't allow to launch an apply worker if it gets restarted. This code was introduced by commit de43897122 but we caught the problem only with the test added by recent commit c91f71b9dc which started failing occasionally in the buildfarm. As per buildfarm. Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra Author: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e79...@enterprisedb.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/82d4a17a17508a4e6ff9038d81a7dfb9f19e104a Modified Files -- src/backend/replication/logical/launcher.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
