From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Snapshot cloning |
Date: | 2007-01-26 16:58:07 |
Message-ID: | 25341.1169830687@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> On 1/26/2007 8:06 AM, Gregory Stark wrote:
>> It seems simpler to have a current_snapshot() function that returns an bytea
>> or a new snapshot data type which set_current_snapshot(bytea) took to change
>> your snapshot. Then you could use tables or out-of-band communication to pass
>> around your snapshots however you please.
>>
>> set_current_snapshot() would have to sanity check that the xmin of the new
>> snapshot isn't older than the current globaloldestxmin.
> That would solve the backend to backend IPC problem nicely.
But it fails on the count of making sure that globaloldestxmin doesn't
advance past the snap you want to use. And exactly how will you pass
a snap through a table? It won't become visible until you commit ...
whereupon your own xmin isn't blocking the advance of globaloldestxmin.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-01-26 17:07:37 | Re: HAVING push-down |
Previous Message | Tom Lane | 2007-01-26 16:51:45 | Re: autovacuum process handling |