Re: PostgreSQL 8.3.4 reproducible crash

Alvaro Herrera <alvherre@commandprompt.com> writes:
> I think this is the easiest way out, and the most robust -- we won't be
> bitten by some other operation that the parser may think of doing.
> (Note that utility commands have their snapshot set in
> PortalRunUtility).  Also, perhaps this would let us clean the mess in
> pg_plan_queries.

After looking at this some more, it seems the problem is that the mess
moves to the callers --- at least the ones that can't count on a snap
being already set.  Either that or we put the samw make-a-snap-if-needed
logic into pg_analyze_and_rewrite; which doesn't seem very attractive
because then we get two separate snapshot creation cycles for parse
analysis and planning.  It seems better to do it in the callers so that
only one cycle is needed.

Another possibility is to merge pg_analyze_and_rewrite and
pg_plan_queries into a single function, but this doesn't appear to
be convenient for all callers.

The good news is that my concern about changing the snapshotting
behavior of multiple-command query strings seems unfounded.  That
is only relevant to exec_simple_query and it's already set up so that
parse analysis, planning, and execution happen one command at a time.
So if a plannable statement comes before a utility statement, a
transaction snapshot would've been acquired before the utility command
executes anyway.
        regards, tom lane