pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Further refine _SPI_execute_plan's rule for atomic execution. 7+ messages / 1 participants [nested] [flat]
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b5eef75391c8e9dd770ba3de9625bb260b086295 Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ab13c46ff4314b3d399b5f5c2e72895f7f4b590a Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b35231989524be8bf7257e695ac61346dda35b7f Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/25d639eea04300e8bc7bc8258a07e19b13dfb1f3 Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cf1443d675c58456e317e6402a5648243ac25d02 Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0d83ced3c91b33839124825b3518c20b1e97df93 Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further refine _SPI_execute_plan's rule for atomic execution. @ 2024-10-16 21:36 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-10-16 21:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further refine _SPI_execute_plan's rule for atomic execution. Commit 2dc1deaea turns out to have been still a brick shy of a load, because CALL statements executing within a plpgsql exception block could still pass the wrong snapshot to stable functions within the CALL's argument list. That happened because standard_ProcessUtility forces isAtomicContext to true if IsTransactionBlock is true, which it always will be inside a subtransaction. Then ExecuteCallStmt would think it does not need to push a new snapshot --- but _SPI_execute_plan didn't do so either, since it thought it was in nonatomic mode. The best fix for this seems to be for _SPI_execute_plan to operate in atomic execution mode if IsSubTransaction() is true, even when the SPI context as a whole is non-atomic. This makes _SPI_execute_plan have the same rules about when non-atomic execution is allowed as _SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed, which seems appropriately symmetric. (If anyone ever tries to allow COMMIT/ROLLBACK inside a subtransaction, this would all need to be rethought ... but I'm unconvinced that such a thing could be logically consistent at all.) For further consistency, also check IsSubTransaction() in SPI_inside_nonatomic_context. That does not matter for its one present-day caller StartTransaction, which can't be reached inside a subtransaction. But if any other callers ever arise, they'd presumably want this definition. Per bug #18656 from Alexander Alehin. Back-patch to all supported branches, like previous fixes in this area. Discussion: https://postgr.es/m/18656-cade1780866ef66c@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c96de42c4b5f5d7bf785265cf26836326e28c6b6 Modified Files -------------- src/backend/executor/spi.c | 14 ++++++++++---- src/pl/plpgsql/src/expected/plpgsql_call.out | 20 ++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 17 +++++++++++++++++ 3 files changed, 47 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-10-16 21:36 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. Tom Lane <tgl@sss.pgh.pa.us> 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. Tom Lane <tgl@sss.pgh.pa.us> 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. Tom Lane <tgl@sss.pgh.pa.us> 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. Tom Lane <tgl@sss.pgh.pa.us> 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. Tom Lane <tgl@sss.pgh.pa.us> 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. Tom Lane <tgl@sss.pgh.pa.us> 2024-10-16 21:36 pgsql: Further refine _SPI_execute_plan's rule for atomic execution. 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