On Wed, Sep 8, 2010 at 6:52 AM, Boszormenyi Zoltan <z...@cybertec.at> wrote: > Fujii Masao írta: >> On Wed, Sep 8, 2010 at 7:04 PM, Boszormenyi Zoltan <z...@cybertec.at> wrote: >> >>> Then there is no use to implement individual sync/async >>> replicated transactions, period. An async replicated transaction >>> that waits for a sync replicated transaction because of locks >>> will become implicitely sync. It just waits for another transactions' >>> sync ack. >>> >> >> Hmm.. it's the same with async transaction (i.e., synchronous_commit = false) >> and sync one (synchronous_commit = true). Async transaction cannot take the >> lock held by sync one until the sync has flushed the WAL. >> > > You are right.
I still don't see why it matters whether you wait before or after releasing locks. As soon as the transaction is marked committed in CLOG, other transactions can potentially see its effects. Holding on to all the locks might mitigate that somewhat, but it's not going to eliminate the problem. And in any event, there is ALWAYS a window of time during which the client doesn't know the transaction has committed but other transactions can potentially see its effects. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers