Re: synchronized snapshots
От | Robert Haas |
---|---|
Тема | Re: synchronized snapshots |
Дата | |
Msg-id | CA+TgmoaQSGd8xCYW9oCQz0sU8CZV_y8-t7yoxiwkZttyi345sw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: synchronized snapshots (Joachim Wieland <joe@mcknight.de>) |
Ответы |
Re: synchronized snapshots
|
Список | pgsql-hackers |
On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland <joe@mcknight.de> wrote: > On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby <jim@nasby.net> wrote: >> I suspect that all the other cases of BEGIN failing would be syntax errors, so >> you would immediately know in testing that something was wrong. A missing file >> is definitely not a syntax error, so we can't really depend on user testing to ensure >> this is handled correctly. IMO, that makes it critical that that error puts us in an >> aborted transaction. > > Why can we not just require the user to verify if his BEGIN query > failed or succeeded? > Is that really too much to ask for? > > Also see what Robert wrote about proxies in between that keep track of > the transaction > state. Consider they see a BEGIN query that fails. How would they know > if the session > is now in an aborted transaction or not in a transaction at all? I think the point here is that we should be consistent. Currently, you can make BEGIN fail by doing it on the standby, and asking for READ WRITE mode: rhaas=# begin transaction read write; ERROR: cannot set transaction read-write mode during recovery After doing that, you are NOT in a transaction context: rhaas=# select 1;?column? ---------- 1 (1 row) So whatever this does should be consistent with that, at least IMHO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: