On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
