On Wed, Sep 8, 2010 at 6:52 AM, Boszormenyi Zoltan <zb@cybertec.at> wrote:
> Fujii Masao írta:
>> On Wed, Sep 8, 2010 at 7:04 PM, Boszormenyi Zoltan <zb@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
