From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: weird hang while running in HS mode |
Date: | 2010-05-13 10:08:05 |
Message-ID: | AANLkTimENYn2TwTcbVOSam8FKxSj--RlCbTT4Ero93Ef@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 13, 2010 at 6:47 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Rollbacks are always flushed to disk, so this explanation doesn't work.
> Even if it were it would take no longer than ~1 sec if everything were
> working correctly on the test system.
Yeah, rollbacks are always flushed sooner or later, but not *immediately*,
since RecordTransactionAbort() calls only XLogInsert() but not XLogFlush().
Until XLogFlush() is executed by another process, the WAL record of rollback
would stay in wal_buffers.
On the other hand, RecordTransactionCommit() calls XLogFlush(),
so commits are always flushed to the disk immediately.
> The "weird hang" is a lock wait and is perfectly normal in database
> systems. Robert says he hasn't checked whether it is reproduceable, so
> there is no evidence to show there is anything other than pilot error,
> at this point.
I was able to reproduce such a hang by not executing another transaction
after rollback. In this case, walsender cannot replicate the rollback
since it's not in the disk.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-05-13 10:12:40 | Re: pg_upgrade code questions |
Previous Message | Simon Riggs | 2010-05-13 09:47:17 | Re: weird hang while running in HS mode |