From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | masao(dot)fujii(at)oss(dot)nttdata(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-09 04:47:43 |
Message-ID: | 20200709.134743.1136524996274963021.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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..
@@ -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?
- "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.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-07-09 04:54:02 | Re: pgsql-hackers archive broken? |
Previous Message | Fujii Masao | 2020-07-09 04:47:27 | Re: [doc] modifying unit from characters to bytes |