From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness |
Date: | 2021-07-27 00:40:11 |
Message-ID: | BC5A4B01-537B-4FE5-A0B7-40D8DC9E0AA4@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/26/21, 5:23 PM, "Fujii Masao" <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> On 2021/07/27 5:27, Bossart, Nathan wrote:
>> +1. I was confused by this when working on a WAL pre-allocation
>> patch [0]. Perhaps it could be replaced by a new parameter and a new
>> field in pg_stat_wal. How about something like log_wal_init_interval,
>> where the value is the minimum amount of time between reporting the
>> number of WAL segments created since the last report?
>
> You mean to introduce new GUC like log_wal_init_interval and that
> the number of WAL files created since the last report will be logged
> every that interval? But isn't it better and simpler to just expose
> the accumulated number of WAL files created, in pg_stat_wal view
> or elsewhere? If so, we can easily get to know the number of WAL files
> created in every interval by checking the view and calculating the diff.
I agree with you about adding a new field to pg_stat_wal. The
parameter would just be a convenient way of logging this information
for future reference. I don't feel strongly about the parameter if
you think the pg_stat_wal addition is enough.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-07-27 00:48:00 | Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness |
Previous Message | Justin Pryzby | 2021-07-27 00:36:52 | Re: needless complexity in StartupXLOG |