| 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: | Whole Thread | Raw Message | 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 |