Re: Proposal: Snapshot cloning

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

In response to

Responses

Browse pgsql-hackers by date

  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