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 20:11:27 |
Message-ID: | 12102.1518466287@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> So what's happening here is that the function get_bug_id, being stable,
> is being called speculatively at plan time for the query where it
> appears in the WHERE clause. For whatever reason, the snapshot it's
> being run in at that time is not the same one actually used for the
> later execution of the query, and the plan-time snapshot doesn't see the
> just-inserted row.
> It looks like what's going on here is that SPI does GetCachedPlan -
> which is where planning will happen - _before_ establishing the new
> snapshot in the non-read-only case (read_only is false here because the
> calling function, test_bug(), is volatile).
Yeah, I came to the same conclusion. I think it's basically accidental
that the given test case works before 9.2: the reason seems to be that
in 9.1, the plancache doesn't pass through the parameter list containing
the value of "my_text", so that the planner is unable to speculatively
execute get_bug_id(). The order of operations in _SPI_execute_plan
is just as wrong though.
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 ...
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
set-snapshot-sooner-in-spi.patch | text/x-diff | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-02-12 21:10:43 | Re: BUG #15060: Row in table not found when using pg function in an expression |
Previous Message | Andrew Gierth | 2018-02-12 19:31:00 | Re: BUG #15060: Row in table not found when using pg function in an expression |