Re: why do we need two snapshots per query?

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: why do we need two snapshots per query?
Date: 2011-11-11 16:29:26
Message-ID: AC7C8990-7C7C-42B3-B9D9-57C33EF64F03@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov11, 2011, at 17:06 , Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-11-11 16:49:14 Re: Manual anti-wraparound vacuums
Previous Message Tom Lane 2011-11-11 16:06:29 Re: why do we need two snapshots per query?