Re: confusing checkpoint_flush_after / bgwriter_flush_after - Mailing list pgsql-hackers

From Tom Lane
Subject Re: confusing checkpoint_flush_after / bgwriter_flush_after
Date
Msg-id 32759.1480117153@sss.pgh.pa.us
Whole thread Raw
In response to Re: confusing checkpoint_flush_after / bgwriter_flush_after  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: confusing checkpoint_flush_after / bgwriter_flush_after  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>>> What we do in some similar cases is put the burden on initdb to fill in
>>> the correct value by modifying postgresql.conf.sample appropriately.
>>> It seems like that could be done easily here too.  And it'd be a
>>> back-patchable fix.

>> I haven't realized initdb can do that. I agree that would be the best 
>> solution.

> Indeed.

> Maybe something like the following, or maybe it should include "bufmgr.h", 
> not sure.

As-is this patch seems like a maintenance time bomb; it really needs to
use the #defines rather than have the values hard-wired in.  However, just
including bufmgr.h in frontend code doesn't work, so I moved the #defines
to pg_config_manual.h, which seems like a more reasonable place for them
anyway.

Pushed with that and some other polishing.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: References to arbitrary database objects that are suitable for pg_dump
Next
From: Tom Lane
Date:
Subject: Re: Fixed pg_class refcache leak when the meta tuple in pg_class in invalid.