Re: max_slot_wal_keep_size and wal_keep_segments

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: david(at)pgmasters(dot)net, alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_slot_wal_keep_size and wal_keep_segments
Date: 2020-07-13 05:14:30
Message-ID: 866c681c-3082-7010-cc9e-bf3b9483c991@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/07/09 13:47, Kyotaro Horiguchi wrote:
> At Thu, 9 Jul 2020 00:37:57 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>>
>>
>> On 2020/07/02 2:18, David Steele wrote:
>>> On 7/1/20 10:54 AM, Alvaro Herrera wrote:
>>>> On 2020-Jul-01, Fujii Masao wrote:
>>>>
>>>>> On 2020/07/01 12:26, Alvaro Herrera wrote:
>>>>>> On 2020-Jun-30, Fujii Masao wrote:
>>>>>>
>>>>>>> When I talked about max_slot_wal_keep_size as new feature in v13
>>>>>>> at the conference, I received the question like "Why are the units of
>>>>>>> setting values in max_slot_wal_keep_size and wal_keep_segments
>>>>>>> different?"
>>>>>>> from audience. That difference looks confusing for users and
>>>>>>> IMO it's better to use the same unit for them. Thought?
>>>>>>
>>>>>> Do we still need wal_keep_segments for anything?
>>>>>
>>>>> Yeah, personally I like wal_keep_segments because its setting is very
>>>>> simple and no extra operations on replication slots are necessary.
>>>>
>>>> Okay.  In that case I +1 the idea of renaming to wal_keep_size.
>>> +1 for renaming to wal_keep_size.
>>
>> I attached the patch that renames wal_keep_segments to wal_keep_size.
>
> It fails on 019_replslot_limit.pl for uncertain reason to me..

I could not reproduce this...

>
>
> @@ -11323,7 +11329,7 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
> * If archiving is enabled, wait for all the required WAL files to be
> * archived before returning. If archiving isn't enabled, the required WAL
> * needs to be transported via streaming replication (hopefully with
> - * wal_keep_segments set high enough), or some more exotic mechanism like
> + * wal_keep_size set high enough), or some more exotic mechanism like
> * polling and copying files from pg_wal with script. We have no knowledge
>
> Isn't this time a good chance to mention replication slots?

+1 to do that. But I found there are other places where replication slots
need to be mentioned. So I think it's better to do this as separate patch.

>
>
> - "ALTER SYSTEM SET wal_keep_segments to 8; SELECT pg_reload_conf();");
> + "ALTER SYSTEM SET wal_keep_size to '128MB'; SELECT pg_reload_conf();");
>
> wal_segment_size to 1MB here so, that conversion is not correct.
> (However, that test works as long as it is more than
> max_slot_wal_keep_size so it's practically no problem.)

So I changed 128MB to 8MB. Is this OK?
I attached the updated version of the patch upthread.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-07-13 05:17:26 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Fujii Masao 2020-07-13 05:11:05 Re: max_slot_wal_keep_size and wal_keep_segments