Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby.
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby. |
Дата | |
Msg-id | 24089.1224710197@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby. (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for
hot standby.
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > On Wed, 2008-10-22 at 16:41 -0400, Tom Lane wrote: >> Hmm, but then why did we not see the same thing before? > The failure definitely came from trying to set SUBCOMMITTED on a > transaction already committed. Ah, I see: prior versions did not bother to make a WAL entry for a subcommit, so there was no case where a replay would try to reverse the later state change to committed. I see from a quick look in xact.c that CommitSubTransaction no longer marks the subxact as subcommitted at all, which makes me wonder what is the point of even having the state. If you intend that we are going to rely 100% on in-memory state to detect our own subcommitted transactions, then why isn't it sufficient to mark the parent committed and then mark the subtransactions committed? An onlooker would see a subtransaction go directly from IN_PROGRESS to COMMITTED, but if the onlooker is too slow to catch the now-very-transient SUBCOMMITTED state, that's what he'd see anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: