On Tue, Aug 16, 2011 at 10:43 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mar ago 16 09:59:04 -0400 2011:
>> On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland <joe@mcknight.de> wrote:
>
>> > 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
>> READ WRITE mode:
>>
>> 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;
>> ?column?
>> ----------
>> 1
>> (1 row)
>>
>> So whatever this does should be consistent with that, at least IMHO.
>
> I think we argued about a very similar problem years ago and the outcome
> was that you should be left in an aborted transaction block; otherwise
> running a dumb SQL script (which has no way to "abort if it fails")
> could wreak serious havoc (?). I think this failure to behave in that
> fashion on the standby is something to be fixed, not imitated.
>
> What this says is that a driver or app seeing BEGIN fail should issue
> ROLLBACK before going further -- which seems the intuitive way to behave
> to me. No?
Maybe. But if we're going to change the behavior of BEGIN, then (1)
we need to think about backward compatibility and (2) we should change
it across the board. It's not for this patch to go invent something
that's inconsistent with what we're already doing elsewhere.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company