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
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 |