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.

I think we'd be far better off to maintain the position that a failed
BEGIN does not start a transaction, under any circumstances.  To do
that, we cannot have this new option attached to the BEGIN, which is a
good thing anyway IMO from a standards compatibility point of view.
It'd be better to make it a separate utility statement.  There is no
logical problem in doing that, and we already have a precedent for
utility statements that do something special before the transaction
snapshot is taken: see LOCK.

In fact, now that I think about it, setting the transaction snapshot
from a utility statement would be functionally useful because then you
could take locks beforehand.

And as a bonus, we don't have a backwards compatibility problem to solve.

                        regards, tom lane

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

Reply via email to