On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jim Nasby <jim@nasby.net> writes:
>> Well, it appears we have a larger problem, as Robert pointed out that trying to start a writable transaction on a
hotstandby 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.
Thenwe 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