On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
