Re: Free WAL caches on switching segments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Free WAL caches on switching segments
Date: 2006-02-13 16:47:58
Message-ID: 2166.1139849278@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> ITAGAKI Takahiro wrote:
>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
>>> I looked this over and I am unsure what this does for us that isn't
>>> already accomplished using the wal_sync_method settings. See xlog.c for
>>> a description of O_DIRECT and when it is used.
>>
>> I proposed it to supplement the cache control. There are some OSes that
>> supports posix_fadvise but not O_DIRECT, for example, NetBSD 4.0
>> (http://www.netbsd.org/Changes/changes-4.0.html).

> Oh, that makes sense then. Let me re-add it to the queue.

Could we see some performance measurements *from those OSes*? The given
test on Linux certainly does not justify adding another operating
system dependency to the WAL code. For that matter, even if it is a big
win on some versions of NetBSD, I'm not sure I'd want to accept it ...
how many NetBSD users do we have who would care?

Depending on OS features we have never depended on before is a *huge*
ongoing maintenance cost, and I have not seen an argument that I think
justifies this one.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-02-13 17:56:01 Re: Free WAL caches on switching segments
Previous Message Tom Lane 2006-02-13 14:57:41 Re: patch correcting the build failure on machines without readline