From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Venkata Balaji N <nag1010(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redesigning checkpoint_segments |
Date: | 2015-02-05 03:37:03 |
Message-ID: | CAA4eK1Jf-jAT+sQJaqGb117HZHZ7UaFjgE6gwwVQ1j-GDrvqtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 5, 2015 at 3:11 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
> On 02/04/2015 12:06 PM, Robert Haas wrote:
> > On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >> Let me push "max_wal_size" and "min_wal_size" again as our new
parameter
> >> names, because:
> >>
> >> * does what it says on the tin
> >> * new user friendly
> >> * encourages people to express it in MB, not segments
> >> * very different from the old name, so people will know it works
differently
> >
> > That's not bad. If we added a hard WAL limit in a future release, how
> > would that fit into this naming scheme?
>
> Well, first, nobody's at present proposing a patch to add a hard limit,
> so I'm reluctant to choose non-obvious names to avoid conflict with a
> feature nobody may ever write. There's a number of reasons a hard limit
> would be difficult and/or undesirable.
>
> If we did add one, I'd suggest calling it "wal_size_limit" or something
> similar.
I think both the names (max_wal_size and wal_size_limit) seems to
indicate the same same thing. Few more suggestions:
typical_wal_size, wal_size_soft_limit?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-02-05 03:47:03 | Re: parallel mode and parallel contexts |
Previous Message | Fujii Masao | 2015-02-05 03:36:20 | Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code |