Horton

Re: why do we need two snapshots per query?

Florian G. Pflug <fgp@phlo.org>

View thread
From: Florian Pflug <fgp@phlo.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-11-11T16:29:26Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix copyright notices, other minor editing in new range-types code.

  2. Redesign the plancache mechanism for more flexibility and efficiency.

On Nov11, 2011, at 17:06 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> On Nov11, 2011, at 16:18 , Robert Haas wrote:
>>> In the extend query protocol scenario, it seems to me that keeping the
>>> snapshot would be both wrong and a bad idea.
> 
>> Hm, but that'd penalize clients who use the extended query protocol, which
>> they have to if they want to transmit out-of-line parameters. You could
>> work around that by making the extended protocol scenario work like the
>> simply protocol scenario if the unnamed statement and/or portal is used.
> 
>> Since clients presumably use pipelined Parse,Bind,Execute messages when
>> using the unnamed statement and portal, they're unlikely to observe the
>> difference between a snapshot taken during Parse, Bind or Execute.
> 
> I think it would be a seriously bad idea to allow the unnamed portal to
> have semantic differences from other portals.  We've gotten enough flak
> about the fact that it had planner behavioral differences (enough so that
> those differences are gone as of HEAD).

Oh, I missed that and worked from the assumption that we're still special-
casing the unnamed case. Since we don't, re-introducing a difference in
behaviour is probably a bad idea.

Still, optimizing only the simple protocol seems weird.

best regards,
Florian Pflug