On Tue, Aug 16, 2011 at 8:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think we'd be far better off to maintain the position that a failed
>>> BEGIN does not start a transaction, under any circumstances.
>
>> Also agreed.
>
>>> To do
>>> that, we cannot have this new option attached to the BEGIN, ...
>
>> Eh, why not?
>
> Maybe I wasn't paying close enough attention to the thread, but I had
> the idea that there was some implementation reason why not. If not,
> we could still load the option onto BEGIN ... but I still find myself
> liking the idea of a separate command better, because of the locking
> issue.
Why does it matter whether you take the locks before or after the snapshot?
If you're concerned with minimizing the race, what you should do is
take all relevant locks in the parent before exporting the snapshot.
I am not wild about adding another toplevel command for this. It
seems a rather narrow use case, and attaching it to BEGIN feels
natural to me. There may be some small benefit also in terms of
minimizing the amount of sanity checking that must be done - for
example, at BEGIN time, you don't have to check for the case where a
snapshot has already been set.
If we did add another toplevel command, what would we call it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company