| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com> |
| Subject: | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |
| Date: | 2010-11-17 01:12:29 |
| Message-ID: | 201011170212.30033.andres@anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wednesday 17 November 2010 02:04:28 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On Wednesday 17 November 2010 01:51:28 Tom Lane wrote:
> >> Well, there's a forced fsync after writing the last page of an xlog
> >> file, but I don't believe that proves that more than 16MB of xlog
> >> buffers is useless. Other processes could still be busy filling the
> >> buffers.
> >
> > Maybe I am missing something, but I think the relevant
> > AdvanceXLInsertBuffer() is currently called with WALInsertLock held?
>
> The fsync is associated with the write, which is not done with insert
> lock held. We're not quite that dumb.
Ah, I see. The XLogWrite in AdvanceXLInsertBuffer is only happening if the head
of the buffer gets to the tail - which is more likely if the wal buffers are
small...
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2010-11-17 01:17:42 | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |
| Previous Message | Tom Lane | 2010-11-17 01:04:28 | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |