From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | ronan(dot)dunklau(at)aiven(dot)io |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_receivewal starting position |
Date: | 2021-07-28 06:22:30 |
Message-ID: | 20210728.152230.2032903346246847782.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 27 Jul 2021 07:50:39 +0200, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> wrote in
> Hello,
>
> I've notived that pg_receivewal logic for deciding which LSN to start
> streaming at consists of:
> - looking up the latest WAL file in our destination folder, and resume from
> here
> - if there isn't, use the current flush location instead.
>
> This behaviour surprised me when using it with a replication slot: I was
> expecting it to start streaming at the last flushed location from the
> replication slot instead. If you consider a backup tool which will take
> pg_receivewal's output and transfer it somewhere else, using the replication
> slot position would be the easiest way to ensure we don't miss WAL files.
>
> Does that make sense ?
>
> I don't know if it should be the default, toggled by a command line flag, or if
> we even should let the user provide a LSN.
*I* think it is completely reasonable (or at least convenient or less
astonishing) that pg_receivewal starts from the restart_lsn of the
replication slot to use. The tool already decides the clean-start LSN
a bit unusual way. And it seems to me that proposed behavior can be
the default when -S is specified.
> I'd be happy to implement any of that if we agree.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-07-28 06:28:03 | Re: Remove client-log from SSL test .gitignore |
Previous Message | Michael Paquier | 2021-07-28 06:20:02 | Re: CREATE SEQUENCE with RESTART option |