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: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2011-11-11T16:00:12Z
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 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.  It would be wrong
> because the user will (I think) expect the query can see all rows that
> were marked as committed prior to Execute message.  It would be a bad
> idea because we'd have to keep that snapshot advertised for the entire
> time between Parse and Execute, even if the client was sitting there
> doing nothing for a long time, which would hold back RecentGlobalXmin.

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.

best regards,
Florian Pflug