]> granicus.if.org Git - postgresql/commit
Save/restore SPI's global variables in SPI_connect() and SPI_finish().
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 8 Sep 2018 00:09:57 +0000 (20:09 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 8 Sep 2018 00:09:57 +0000 (20:09 -0400)
commit82ebf39fcb25236b60f05e4483d86cb4144fce8a
treeca5de9d95b75a85abc1b3618d89b6b2ff17b9855
parent2ef5c12ad5b613fd4f4755122aa837689f7c5fd5
Save/restore SPI's global variables in SPI_connect() and SPI_finish().

This patch removes two sources of interference between nominally
independent functions when one SPI-using function calls another,
perhaps without knowing that it does so.

Chapman Flack pointed out that xml.c's query_to_xml_internal() expects
SPI_tuptable and SPI_processed to stay valid across datatype output
function calls; but it's possible that such a call could involve
re-entrant use of SPI.  It seems likely that there are similar hazards
elsewhere, if not in the core code then in third-party SPI users.
Previously SPI_finish() reset SPI's API globals to zeroes/nulls, which
would typically make for a crash in such a situation.  Restoring them
to the values they had at SPI_connect() seems like a considerably more
useful behavior, and it still meets the design goal of not leaving any
dangling pointers to tuple tables of the function being exited.

Also, cause SPI_connect() to reset these variables to zeroes/nulls after
saving them.  This prevents interference in the opposite direction: it's
possible that a SPI-using function that's only ever been tested standalone
contains assumptions that these variables start out as zeroes.  That was
the case as long as you were the outermost SPI user, but not so much for
an inner user.  Now it's consistent.

Report and fix suggestion by Chapman Flack, actual patch by me.
Back-patch to all supported branches.

Discussion: https://postgr.es/m/9fa25bef-2e4f-1c32-22a4-3ad0723c4a17@anastigmatix.net
src/backend/executor/spi.c
src/include/executor/spi_priv.h