I wrote:
> The attached patch makes it better and doesn't seem to break any
> regression tests. I'm not sure how nervous I am about unexpected
> side-effects ...
Oh ... my nervousness was justified. This is no good at all; it'd
create the same problem introduced at the client query level by
commit d573e239f and later reverted by 532994299, namely that we'd
be reading tables using a snapshot acquired before we've acquired
locks on said tables.
To really fix this complaint, it seems like we'd need to take a snapshot
before planning and then a new one after planning, matching what happens
in the main query pipeline. That's pretty nasty for performance :-(
... it would more or less double the load on the ProcArray for SPI-heavy
applications.
One could argue that, since this function is throwing an error, it's
not really stable --- that implies a lack of interesting side-effects.
I don't find that argument totally convincing, but the price of avoiding
the error might be more than we really want to pay.
regards, tom lane
