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: http://www.postgresql.org/mailpref/pgsql-hackers