From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: why do we need two snapshots per query? |
Date: | 2011-11-11 16:00:12 |
Message-ID: | A70E3B1B-73A5-476B-AE21-42099772B965@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-11 16:06:29 | Re: why do we need two snapshots per query? |
Previous Message | Tom Lane | 2011-11-11 15:47:48 | Re: Manual anti-wraparound vacuums |