On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
