Re: Snapshot synchronization, again... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Snapshot synchronization, again...
Date
Msg-id 10047.1298335180@sss.pgh.pa.us
Whole thread Raw
In response to Re: Snapshot synchronization, again...  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> That's true too.  So let's discuss the syntax.  Maybe
>     START TRANSACTION SNAPSHOT '\xdeadbeef';

> This kind of extension seems ugly though; maybe we should consider
>     START TRANSACTION (snapshot='\xdeadbeef');
> (like VACUUM, EXPLAIN and COPY) or some such?

+1 for the latter, mainly because (I think) you could avoid making
SNAPSHOT into an actual parser keyword that way.

> I don't think we need another "top-level" command for this.

Mmm ... one possible objection is that if it's hard-wired into the START
TRANSACTION syntax, then there is no way to take any locks before
establishing the snapshot.  Right offhand, though, I can't see a
use-case for doing that, given that the snapshot itself would be older
than any locks that the secondary transaction could grab.

I suppose that a separate top-level command might be nicer just to avoid
touching the syntax of START TRANSACTION.  If we put the option into
parens as above, there seems little chance of colliding with future spec
extensions, but it's a tad ugly looking.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Snapshot synchronization, again...
Next
From: Andrew Dunstan
Date:
Subject: Re: validating foreign tables