On Wed, Mar 16, 2011 at 1:43 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > 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.
The transaction IS committed, but only locally. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
