On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland <j...@mcknight.de> wrote:
> On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby <j...@nasby.net> wrote:
>> I suspect that all the other cases of BEGIN failing would be syntax errors, 
>> so
>> you would immediately know in testing that something was wrong. A missing 
>> file
>> is definitely not a syntax error, so we can't really depend on user testing 
>> to ensure
>> this is handled correctly. IMO, that makes it critical that that error puts 
>> us in an
>> aborted transaction.
> Why can we not just require the user to verify if his BEGIN query
> failed or succeeded?
> Is that really too much to ask for?
> Also see what Robert wrote about proxies in between that keep track of
> the transaction
> state. Consider they see a BEGIN query that fails. How would they know
> if the session
> is now in an aborted transaction or not in a transaction at all?

I think the point here is that we should be consistent.  Currently,
you can make BEGIN fail by doing it on the standby, and asking for

rhaas=# begin transaction read write;
ERROR:  cannot set transaction read-write mode during recovery

After doing that, you are NOT in a transaction context:

rhaas=# select 1;
(1 row)

So whatever this does should be consistent with that, at least IMHO.

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