pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA 6+ messages / 1 participants [nested] [flat]
* pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA @ 2026-01-22 23:35 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-01-22 23:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDATE. Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO UPDATE rejects partitioned target tables. (This may have been accurate when the patch was written, but it was already obsolete when committed.) Hence, there's an assertion that we can't see ItemPointerIndicatesMovedPartitions() in that path, but the assertion is triggerable. Some other places throw error if they see a moved-across-partitions tuple, but there seems no need for that here, because if we just retry then we get the same behavior as in the update-within-partition case, as demonstrated by the new isolation test. So fix by deleting the faulty Assert. (The fact that this is the fix doubtless explains why we've heard no field complaints: the behavior of a non-assert build is fine.) The TM_Deleted case contains a cargo-culted copy of the same Assert, which I also deleted to avoid confusion, although I believe that one is actually not triggerable. Per our code coverage report, neither the TM_Updated nor the TM_Deleted case were reached at all by existing tests, so this patch adds tests for both. Reported-by: Dmitry Koval <d.koval@postgrespro.ru> Author: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/4b760a181ab220f425a6fe8e08335891b0ba62d4 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 9 ---- .../expected/insert-conflict-do-update-4.out | 63 ++++++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/insert-conflict-do-update-4.spec | 42 +++++++++++++++ 4 files changed, 106 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA @ 2026-01-22 23:35 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-01-22 23:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDATE. Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO UPDATE rejects partitioned target tables. (This may have been accurate when the patch was written, but it was already obsolete when committed.) Hence, there's an assertion that we can't see ItemPointerIndicatesMovedPartitions() in that path, but the assertion is triggerable. Some other places throw error if they see a moved-across-partitions tuple, but there seems no need for that here, because if we just retry then we get the same behavior as in the update-within-partition case, as demonstrated by the new isolation test. So fix by deleting the faulty Assert. (The fact that this is the fix doubtless explains why we've heard no field complaints: the behavior of a non-assert build is fine.) The TM_Deleted case contains a cargo-culted copy of the same Assert, which I also deleted to avoid confusion, although I believe that one is actually not triggerable. Per our code coverage report, neither the TM_Updated nor the TM_Deleted case were reached at all by existing tests, so this patch adds tests for both. Reported-by: Dmitry Koval <d.koval@postgrespro.ru> Author: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9f7c803c91584fb6e4b45dc87de44bac370477a9 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 9 ---- .../expected/insert-conflict-do-update-4.out | 63 ++++++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/insert-conflict-do-update-4.spec | 42 +++++++++++++++ 4 files changed, 106 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA @ 2026-01-22 23:35 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-01-22 23:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDATE. Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO UPDATE rejects partitioned target tables. (This may have been accurate when the patch was written, but it was already obsolete when committed.) Hence, there's an assertion that we can't see ItemPointerIndicatesMovedPartitions() in that path, but the assertion is triggerable. Some other places throw error if they see a moved-across-partitions tuple, but there seems no need for that here, because if we just retry then we get the same behavior as in the update-within-partition case, as demonstrated by the new isolation test. So fix by deleting the faulty Assert. (The fact that this is the fix doubtless explains why we've heard no field complaints: the behavior of a non-assert build is fine.) The TM_Deleted case contains a cargo-culted copy of the same Assert, which I also deleted to avoid confusion, although I believe that one is actually not triggerable. Per our code coverage report, neither the TM_Updated nor the TM_Deleted case were reached at all by existing tests, so this patch adds tests for both. Reported-by: Dmitry Koval <d.koval@postgrespro.ru> Author: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3fabfc6595ced067a22ac309ec94c79e86d61494 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 9 ---- .../expected/insert-conflict-do-update-4.out | 63 ++++++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/insert-conflict-do-update-4.spec | 42 +++++++++++++++ 4 files changed, 106 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA @ 2026-01-22 23:35 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-01-22 23:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDATE. Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO UPDATE rejects partitioned target tables. (This may have been accurate when the patch was written, but it was already obsolete when committed.) Hence, there's an assertion that we can't see ItemPointerIndicatesMovedPartitions() in that path, but the assertion is triggerable. Some other places throw error if they see a moved-across-partitions tuple, but there seems no need for that here, because if we just retry then we get the same behavior as in the update-within-partition case, as demonstrated by the new isolation test. So fix by deleting the faulty Assert. (The fact that this is the fix doubtless explains why we've heard no field complaints: the behavior of a non-assert build is fine.) The TM_Deleted case contains a cargo-culted copy of the same Assert, which I also deleted to avoid confusion, although I believe that one is actually not triggerable. Per our code coverage report, neither the TM_Updated nor the TM_Deleted case were reached at all by existing tests, so this patch adds tests for both. Reported-by: Dmitry Koval <d.koval@postgrespro.ru> Author: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3f56de3aad1bcffae01dc2c22a41518a18d25d77 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 9 ---- .../expected/insert-conflict-do-update-4.out | 63 ++++++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/insert-conflict-do-update-4.spec | 42 +++++++++++++++ 4 files changed, 106 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA @ 2026-01-22 23:35 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-01-22 23:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDATE. Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO UPDATE rejects partitioned target tables. (This may have been accurate when the patch was written, but it was already obsolete when committed.) Hence, there's an assertion that we can't see ItemPointerIndicatesMovedPartitions() in that path, but the assertion is triggerable. Some other places throw error if they see a moved-across-partitions tuple, but there seems no need for that here, because if we just retry then we get the same behavior as in the update-within-partition case, as demonstrated by the new isolation test. So fix by deleting the faulty Assert. (The fact that this is the fix doubtless explains why we've heard no field complaints: the behavior of a non-assert build is fine.) The TM_Deleted case contains a cargo-culted copy of the same Assert, which I also deleted to avoid confusion, although I believe that one is actually not triggerable. Per our code coverage report, neither the TM_Updated nor the TM_Deleted case were reached at all by existing tests, so this patch adds tests for both. Reported-by: Dmitry Koval <d.koval@postgrespro.ru> Author: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7eb3422eb4f7751518da743b21ac6c5266ddccdd Modified Files -------------- src/backend/executor/nodeModifyTable.c | 9 ---- .../expected/insert-conflict-do-update-4.out | 63 ++++++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/insert-conflict-do-update-4.spec | 42 +++++++++++++++ 4 files changed, 106 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA @ 2026-01-22 23:35 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-01-22 23:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDATE. Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO UPDATE rejects partitioned target tables. (This may have been accurate when the patch was written, but it was already obsolete when committed.) Hence, there's an assertion that we can't see ItemPointerIndicatesMovedPartitions() in that path, but the assertion is triggerable. Some other places throw error if they see a moved-across-partitions tuple, but there seems no need for that here, because if we just retry then we get the same behavior as in the update-within-partition case, as demonstrated by the new isolation test. So fix by deleting the faulty Assert. (The fact that this is the fix doubtless explains why we've heard no field complaints: the behavior of a non-assert build is fine.) The TM_Deleted case contains a cargo-culted copy of the same Assert, which I also deleted to avoid confusion, although I believe that one is actually not triggerable. Per our code coverage report, neither the TM_Updated nor the TM_Deleted case were reached at all by existing tests, so this patch adds tests for both. Reported-by: Dmitry Koval <d.koval@postgrespro.ru> Author: Joseph Koshakow <koshy44@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/55b5859d41e3ee78aeb09249ec395062cc17f8f4 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 9 ---- .../expected/insert-conflict-do-update-4.out | 63 ++++++++++++++++++++++ src/test/isolation/isolation_schedule | 1 + .../specs/insert-conflict-do-update-4.spec | 42 +++++++++++++++ 4 files changed, 106 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-01-22 23:35 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-22 23:35 pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA Tom Lane <tgl@sss.pgh.pa.us> 2026-01-22 23:35 pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA Tom Lane <tgl@sss.pgh.pa.us> 2026-01-22 23:35 pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA Tom Lane <tgl@sss.pgh.pa.us> 2026-01-22 23:35 pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA Tom Lane <tgl@sss.pgh.pa.us> 2026-01-22 23:35 pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA Tom Lane <tgl@sss.pgh.pa.us> 2026-01-22 23:35 pgsql: Remove faulty Assert in partitioned INSERT...ON CONFLICT DO UPDA 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