On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Jim Nasby <j...@nasby.net> writes:
>> Well, it appears we have a larger problem, as Robert pointed out that trying 
>> to start a writable transaction on a hot standby leaves 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 we can decide on the API for 
>> synchronized snapshots that makes sense instead of working around the 
>> behavior of BEGIN.
> I'm not convinced by the above argument, because it requires that
> you pretend there's a significant difference between syntax errors and
> "run time" errors (whatever those are).  Syntax errors in a BEGIN
> command are not going to leave you in an aborted transaction, because
> the backend is not going to recognize the command as a BEGIN at all.
> This means that frontends *must* be capable of dealing with the case
> that a failed BEGIN didn't start a transaction.  (Either that, or
> they just assume their commands are always syntactically perfect,
> which seems like pretty fragile programming to me; and the more weird
> nonstandard options we load onto BEGIN, the less tenable the position
> becomes.  For example, if you feed BEGIN option-foo to a server that's
> a bit older than you thought it was, you will get a syntax error.)
> If we have some failure cases that start a transaction and some that do
> not, we just have a mess, IMO.

More or less agreed.

> 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?

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to