| 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:01:24 |
| Message-ID: | 201011170201.24782.andres@anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wednesday 17 November 2010 01:51:28 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On Wednesday 17 November 2010 00:31:34 Tom Lane wrote:
> >> Well, we're not going to increase the default to gigabytes
> >
> > Especially not as I don't think it will have any effect after
> > wal_segment_size as that will force a write-out anyway. Or am I
> > misremembering the implementation?
>
> 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?
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-11-17 01:04:28 | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |
| Previous Message | Tom Lane | 2010-11-17 00:51:28 | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |