Re: synchronized snapshots - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: synchronized snapshots
Date
Msg-id 06090E92-DC66-479A-B7B2-8BF5B047865E@nasby.net
Whole thread Raw
In response to Re: synchronized snapshots  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: synchronized snapshots
List pgsql-hackers
On Aug 16, 2011, at 5:40 PM, Jeff Davis wrote:
> On Tue, 2011-08-16 at 11:01 -0500, Jim Nasby wrote:
>> Also, an invalid transaction seems to be the result of least
>> surprise... if you cared enough to begin a transaction, you're going
>> to expect that either everything between that and the COMMIT succeeds
>> or fails, not something in-between.
>
> Agreed.
>
> Perhaps we need a new utility command to set the snapshot to make the
> error handling a little more obvious?

Well, it appears we have a larger problem, as Robert pointed out that trying to start a writable transaction on a hot
standbyleaves you not in a transaction (which I feel is a problem). 

So IMHO the right thing to do here is make it so that runtime errors in BEGIN leave you in an invalid transaction. Then
wecan decide on the API for synchronized snapshots that makes sense instead of working around the behavior of BEGIN. 

I guess the big question to answer now is: what's the backwards compatibility impact of changing how BEGIN deals with
runtimeerrors? 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: synchronized snapshots
Next
From: Tatsuo Ishii
Date:
Subject: Finding tables dropped by DROP TABLE CASCADE