Re: [HACKERS] fsync method checking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Spraul <manfred(at)colorfullife(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, pgsql-performance(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] fsync method checking
Date: 2003-12-12 21:28:47
Message-ID: 22121.1071264527@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> One advantage of a seperate write and fsync call is better performance
> for the writes that are triggered within AdvanceXLInsertBuffer: I'm not
> sure how often that's necessary, but it's a write while holding both the
> WALWriteLock and WALInsertLock. If every write contains an implicit
> sync, that call would be much more expensive than necessary.

Ideally that path isn't taken very often. But I'm currently having a
discussion off-list with a CMU student who seems to be seeing a case
where it happens a lot. (She reports that both WALWriteLock and
WALInsertLock are causes of a lot of process blockages, which seems to
mean that a lot of the WAL I/O is being done with both held, which would
have to mean that AdvanceXLInsertBuffer is doing the I/O. More when we
figure out what's going on exactly...)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Smith 2003-12-12 21:32:38 Re: Resurrecting pg_upgrade
Previous Message Thomas Swan 2003-12-12 21:14:33 Re: Resurrecting pg_upgrade

Browse pgsql-performance by date

  From Date Subject
Next Message William Yu 2003-12-12 22:02:03 Update on putting WAL on ramdisk/
Previous Message Mark Kirkwood 2003-12-12 21:11:29 Re: Performance related to size of tables