Re: Sync Rep and shutdown Re: Sync Rep v19
От | Fujii Masao |
---|---|
Тема | Re: Sync Rep and shutdown Re: Sync Rep v19 |
Дата | |
Msg-id | AANLkTikwH3TTrLnyvamCwUf=M92H-b5+DRWJ9x6nKW0Z@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sync Rep and shutdown Re: Sync Rep v19 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Sync Rep and shutdown Re: Sync Rep v19
|
Список | pgsql-hackers |
On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote: > The problem is that there may be another backend B waiting on a lock > held by A. If backend A exits cleanly (without a PANIC), it will > remove itself from the ProcArray and release locks. That wakes up A, > which can now go do its thing. If the operating system is a bit on > the slow side delivering the signal to B, then the client to which B > is connected might manage to see a database state that shows the > transaction previous running in A as committed, even though that > transaction wasn't committed. That would stink, because the whole > point of having A hold onto locks until the standby ack'd the commit > was that no other transaction would see it as committed until it was > replicated. The lock can be released also when the transaction running in A is rollbacked. So I could not understand why the client wrongly always see the transaction as commtted even though it's not committed. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: