Re: Transaction Snapshot Cloning

On 1/12/08, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> >> On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
> >>> [ blanches... ] Can you say "security hole"?
> >
> >> Static on the line, sorry.
> >> I'm hearing "useful superuser-only capability". ;-)
> >
> > It would be far *more* useful if it didn't have to be superuser-only.
> > And since the actual details of the snapshot content are really of
> > zero interest to the user, I think making it pass through his hands
> > is simply misdesign.
>
> Well we already have the snapshot appearing in txid_current_snapshot(). It
> wouldn't be too hard to go through that and verify that it satisfies the
> current minimum requirements (xmin >= globalxmin and all visible xids are
> committed).

IMHO the txid_snapshot is inappropriate for such use. It is really
not meant to be fed back to core code. The whole 8byteness would
be totally pointless. The data passing user hands creates new
error situations.

Better would be something like this:

pg_publish_transaction_state()

returns unique random unguessable cookie. Internally it stores
the xid, snapshot and potentially any other interesting state.
The state will be valid until the transaction end.

Then later user can call in some other connection:

pg_use_transaction_state(<cookie>)

that will then use the state. Main plus of such scheme is that
user can freely decide how it wants to use the cookie, without
any security problems. Also it hides actual state saved from
user which means it can be changed easily.

--
marko