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

On Mon, Feb 12, 2018 at 9:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

I'm not sure I understand. When's the snapshot used for planning actually
taken here?

.m