Re: Transaction Snapshot Cloning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction Snapshot Cloning
Date: 2008-01-11 20:05:34
Message-ID: 24020.1200081934@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> If we had a function
> replace_serializable_snapshot(master_xid, txid_snapshot)
> this would allow us to use the txid_snapshot values to replace our
> transaction's serializable snapshot.

... whereupon we'd get wrong answers. Certainly you could not allow
transaction xmin to go backwards, and I'm not sure what other
restrictions there would be, but the whole thing gives me the willies.

> What I'm thinking about is how we might use this to have multiple
> sessions working simultaneously on tasks like unloading data,

Then what you want is a function that says "clone the snapshot of that
specified other transaction". Not a function that lets the user
substitute random snapshot data and tell you he thinks it's valid.
The user isn't going to have any legal way to transfer the data between
backends anyway, since no transaction can see results of an uncommitted
other transaction. There *has* to be some backdoor channel involved
there, and you might as well make it carry the data without the user
touching it.

The whole thing seems a bit backwards anyway. What you'd really want
for ease of use is some kind of "fork this session" operation, that
is push the info to a new process not pull it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gokulakannan Somasundaram 2008-01-11 20:31:08 Re: Transaction Snapshot Cloning
Previous Message Simon Riggs 2008-01-11 19:32:24 Re: Dynamic Partitioning using Segment Visibility Maps