Re: BUG #15060: Row in table not found when using pg function in an expression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, dejan(dot)petrovic(at)islonline(dot)com
Subject: Re: BUG #15060: Row in table not found when using pg function in an expression
Date: 2018-02-12 21:10:43
Message-ID: 14538.1518469843@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2018-02-13 02:15:31 Re: PostgreSQL crashes with SIGSEGV
Previous Message Tom Lane 2018-02-12 20:11:27 Re: BUG #15060: Row in table not found when using pg function in an expression