pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Obtain required table lock during cross-table constraint updates 13+ messages / 1 participants [nested] [flat]
* pgsql: Obtain required table lock during cross-table constraint updates @ 2025-06-29 17:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-06-29 17:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table constraint updates. Sometimes a table's constraint may depend on a column of another table, so that we have to update the constraint when changing the referenced column's type. We need to have lock on the constraint's table to do that. ATPostAlterTypeCleanup believed that this case was only possible for FOREIGN KEY constraints, but it's wrong at least for CHECK and EXCLUDE constraints; and in general, we'd probably need exclusive lock to alter any sort of constraint. So just remove the contype check and acquire lock for any other table. This prevents a "you don't have lock" assertion failure, though no ill effect is observed in production builds. We'll error out later anyway because we don't presently support physically altering column types within stored composite columns. But the catalog-munging is basically all there, so we may as well make that part work. Bug: #18970 Reported-by: Alexander Lakhin <exclusion@gmail.com> Diagnosed-by: jian he <jian.universality@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/614ffb26d1cd9a068e8ba2761a5aad64100f4d6d Modified Files -------------- src/backend/commands/tablecmds.c | 21 +++++++++++---------- src/test/regress/expected/alter_table.out | 7 +++++++ src/test/regress/sql/alter_table.sql | 9 +++++++++ 3 files changed, 27 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table constraint updates @ 2025-06-29 17:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-06-29 17:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table constraint updates. Sometimes a table's constraint may depend on a column of another table, so that we have to update the constraint when changing the referenced column's type. We need to have lock on the constraint's table to do that. ATPostAlterTypeCleanup believed that this case was only possible for FOREIGN KEY constraints, but it's wrong at least for CHECK and EXCLUDE constraints; and in general, we'd probably need exclusive lock to alter any sort of constraint. So just remove the contype check and acquire lock for any other table. This prevents a "you don't have lock" assertion failure, though no ill effect is observed in production builds. We'll error out later anyway because we don't presently support physically altering column types within stored composite columns. But the catalog-munging is basically all there, so we may as well make that part work. Bug: #18970 Reported-by: Alexander Lakhin <exclusion@gmail.com> Diagnosed-by: jian he <jian.universality@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8319e5cb5493046e65d60da3cc17ab78c91749b1 Modified Files -------------- src/backend/commands/tablecmds.c | 21 +++++++++++---------- src/test/regress/expected/alter_table.out | 7 +++++++ src/test/regress/sql/alter_table.sql | 9 +++++++++ 3 files changed, 27 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table constraint updates @ 2025-06-29 17:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-06-29 17:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table constraint updates. Sometimes a table's constraint may depend on a column of another table, so that we have to update the constraint when changing the referenced column's type. We need to have lock on the constraint's table to do that. ATPostAlterTypeCleanup believed that this case was only possible for FOREIGN KEY constraints, but it's wrong at least for CHECK and EXCLUDE constraints; and in general, we'd probably need exclusive lock to alter any sort of constraint. So just remove the contype check and acquire lock for any other table. This prevents a "you don't have lock" assertion failure, though no ill effect is observed in production builds. We'll error out later anyway because we don't presently support physically altering column types within stored composite columns. But the catalog-munging is basically all there, so we may as well make that part work. Bug: #18970 Reported-by: Alexander Lakhin <exclusion@gmail.com> Diagnosed-by: jian he <jian.universality@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c15798cf94c452f057c6b8dd38c904bb30a8864d Modified Files -------------- src/backend/commands/tablecmds.c | 21 +++++++++++---------- src/test/regress/expected/alter_table.out | 7 +++++++ src/test/regress/sql/alter_table.sql | 9 +++++++++ 3 files changed, 27 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table constraint updates @ 2025-06-29 17:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-06-29 17:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table constraint updates. Sometimes a table's constraint may depend on a column of another table, so that we have to update the constraint when changing the referenced column's type. We need to have lock on the constraint's table to do that. ATPostAlterTypeCleanup believed that this case was only possible for FOREIGN KEY constraints, but it's wrong at least for CHECK and EXCLUDE constraints; and in general, we'd probably need exclusive lock to alter any sort of constraint. So just remove the contype check and acquire lock for any other table. This prevents a "you don't have lock" assertion failure, though no ill effect is observed in production builds. We'll error out later anyway because we don't presently support physically altering column types within stored composite columns. But the catalog-munging is basically all there, so we may as well make that part work. Bug: #18970 Reported-by: Alexander Lakhin <exclusion@gmail.com> Diagnosed-by: jian he <jian.universality@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bbfcbc4cde4a9fb5b1d91acc3d8efc6f868c2684 Modified Files -------------- src/backend/commands/tablecmds.c | 21 +++++++++++---------- src/test/regress/expected/alter_table.out | 7 +++++++ src/test/regress/sql/alter_table.sql | 9 +++++++++ 3 files changed, 27 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table constraint updates @ 2025-06-29 17:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-06-29 17:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table constraint updates. Sometimes a table's constraint may depend on a column of another table, so that we have to update the constraint when changing the referenced column's type. We need to have lock on the constraint's table to do that. ATPostAlterTypeCleanup believed that this case was only possible for FOREIGN KEY constraints, but it's wrong at least for CHECK and EXCLUDE constraints; and in general, we'd probably need exclusive lock to alter any sort of constraint. So just remove the contype check and acquire lock for any other table. This prevents a "you don't have lock" assertion failure, though no ill effect is observed in production builds. We'll error out later anyway because we don't presently support physically altering column types within stored composite columns. But the catalog-munging is basically all there, so we may as well make that part work. Bug: #18970 Reported-by: Alexander Lakhin <exclusion@gmail.com> Diagnosed-by: jian he <jian.universality@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/13f1e9f26a112623c07f55b88b87530649d7155d Modified Files -------------- src/backend/commands/tablecmds.c | 21 +++++++++++---------- src/test/regress/expected/alter_table.out | 7 +++++++ src/test/regress/sql/alter_table.sql | 9 +++++++++ 3 files changed, 27 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table constraint updates @ 2025-06-29 17:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-06-29 17:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table constraint updates. Sometimes a table's constraint may depend on a column of another table, so that we have to update the constraint when changing the referenced column's type. We need to have lock on the constraint's table to do that. ATPostAlterTypeCleanup believed that this case was only possible for FOREIGN KEY constraints, but it's wrong at least for CHECK and EXCLUDE constraints; and in general, we'd probably need exclusive lock to alter any sort of constraint. So just remove the contype check and acquire lock for any other table. This prevents a "you don't have lock" assertion failure, though no ill effect is observed in production builds. We'll error out later anyway because we don't presently support physically altering column types within stored composite columns. But the catalog-munging is basically all there, so we may as well make that part work. Bug: #18970 Reported-by: Alexander Lakhin <exclusion@gmail.com> Diagnosed-by: jian he <jian.universality@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/25cab4473525cd3705fc8ee524b85721db967b65 Modified Files -------------- src/backend/commands/tablecmds.c | 21 +++++++++++---------- src/test/regress/expected/alter_table.out | 7 +++++++ src/test/regress/sql/alter_table.sql | 9 +++++++++ 3 files changed, 27 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a10f21e6ce549705f194b8fdb28e685403e7579d Modified Files -------------- src/backend/commands/tablecmds.c | 22 ++++++++++++++++++++++ src/test/regress/expected/alter_table.out | 8 ++++++++ src/test/regress/expected/generated_stored.out | 12 ++++++++++++ src/test/regress/expected/generated_virtual.out | 9 +++++++++ src/test/regress/sql/alter_table.sql | 8 ++++++++ src/test/regress/sql/generated_stored.sql | 13 +++++++++++++ src/test/regress/sql/generated_virtual.sql | 13 +++++++++++++ 7 files changed, 85 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3d7a96871c71dc0e6d2614eb4a68179bc7e383db Modified Files -------------- src/backend/commands/tablecmds.c | 22 ++++++++++++++++++++++ src/test/regress/expected/alter_table.out | 8 ++++++++ src/test/regress/expected/generated_stored.out | 12 ++++++++++++ src/test/regress/expected/generated_virtual.out | 9 +++++++++ src/test/regress/sql/alter_table.sql | 8 ++++++++ src/test/regress/sql/generated_stored.sql | 13 +++++++++++++ src/test/regress/sql/generated_virtual.sql | 13 +++++++++++++ 7 files changed, 85 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f9ba071cc5bdd2a98c361b5a75e995ffaa0ec787 Modified Files -------------- src/backend/commands/tablecmds.c | 8 ++++++++ src/test/regress/expected/alter_table.out | 4 ++++ src/test/regress/sql/alter_table.sql | 4 ++++ 3 files changed, 16 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6d4395b4021d5f2640f2aadece1dad650b1e7037 Modified Files -------------- src/backend/commands/tablecmds.c | 22 ++++++++++++++++++++++ src/test/regress/expected/alter_table.out | 8 ++++++++ src/test/regress/expected/generated.out | 24 ++++++++++++++++++++++++ src/test/regress/sql/alter_table.sql | 8 ++++++++ src/test/regress/sql/generated.sql | 25 +++++++++++++++++++++++++ 5 files changed, 87 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e6dd6e6ee6e1443441088173231fe9085ce4b912 Modified Files -------------- src/backend/commands/tablecmds.c | 22 ++++++++++++++++++++++ src/test/regress/expected/alter_table.out | 8 ++++++++ src/test/regress/sql/alter_table.sql | 8 ++++++++ 3 files changed, 38 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e902f818191fb7adce9d3d14150f56e528662fa9 Modified Files -------------- src/backend/commands/tablecmds.c | 22 ++++++++++++++++++++++ src/test/regress/expected/alter_table.out | 8 ++++++++ src/test/regress/sql/alter_table.sql | 8 ++++++++ 3 files changed, 38 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
* pgsql: Obtain required table lock during cross-table updates, redux. @ 2025-07-03 17:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 13+ messages in thread From: Tom Lane @ 2025-07-03 17:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he <jian.universality@gmail.com> Author: jian he <jian.universality@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d36980b7159a343ec56baca40bfe6c67765095b7 Modified Files -------------- src/backend/commands/tablecmds.c | 22 ++++++++++++++++++++++ src/test/regress/expected/alter_table.out | 8 ++++++++ src/test/regress/sql/alter_table.sql | 8 ++++++++ 3 files changed, 38 insertions(+) ^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2025-07-03 17:46 UTC | newest] Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-06-29 17:56 pgsql: Obtain required table lock during cross-table constraint updates Tom Lane <tgl@sss.pgh.pa.us> 2025-06-29 17:56 pgsql: Obtain required table lock during cross-table constraint updates Tom Lane <tgl@sss.pgh.pa.us> 2025-06-29 17:56 pgsql: Obtain required table lock during cross-table constraint updates Tom Lane <tgl@sss.pgh.pa.us> 2025-06-29 17:56 pgsql: Obtain required table lock during cross-table constraint updates Tom Lane <tgl@sss.pgh.pa.us> 2025-06-29 17:56 pgsql: Obtain required table lock during cross-table constraint updates Tom Lane <tgl@sss.pgh.pa.us> 2025-06-29 17:56 pgsql: Obtain required table lock during cross-table constraint updates Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us> 2025-07-03 17:46 pgsql: Obtain required table lock during cross-table updates, redux. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox