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 hot
standbyleaves 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.
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
