aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonpath_exec.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-06-07 13:27:26 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-06-07 13:27:26 -0400
commit2dc1deaea0354ce8427abd8c6b11f9c004a65f24 (patch)
tree65867ffcd35b9da53eb91524cd8ed53a46819193 /src/backend/utils/adt/jsonpath_exec.c
parentd92573adcb02564439086d1c257d7821606a3115 (diff)
downloadpostgresql-2dc1deaea0354ce8427abd8c6b11f9c004a65f24.tar.gz
postgresql-2dc1deaea0354ce8427abd8c6b11f9c004a65f24.zip
Fix behavior of stable functions called from a CALL's argument list.
If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal snapshot, which had been acquired at the start of the current SQL command. This'd lead to seeing stale values of rows modified since the start of the command. This is arguably a bug in 84f5c2908: I failed to see that "are we in non-atomic mode" needs to be defined the same way as it is further down in _SPI_execute_plan, i.e. check !_SPI_current->atomic not just options->allow_nonatomic. Alternatively the blame could be laid on plpgsql, which is unconditionally passing allow_nonatomic = true for CALL/DO even when it knows it's in an atomic context. However, fixing it in spi.c seems like a better idea since that will also fix the problem for any extensions that may have copied plpgsql's coding pattern. While here, update an obsolete comment about _SPI_execute_plan's snapshot management. Per report from Victor Yegorov. Back-patch to all supported versions. Discussion: https://postgr.es/m/CAGnEboiRe+fG2QxuBO2390F7P8e2MQ6UyBjZSL_w1Cej+E4=Vw@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/jsonpath_exec.c')
0 files changed, 0 insertions, 0 deletions