Re: Proposal: Snapshot cloning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: Snapshot cloning
Date
Msg-id 25341.1169830687@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: Snapshot cloning  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Proposal: Snapshot cloning  (Gregory Stark <stark@enterprisedb.com>)
Re: Proposal: Snapshot cloning  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Jan Wieck <JanWieck@Yahoo.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: autovacuum process handling
Next
From: "Simon Riggs"
Date:
Subject: Re: HAVING push-down