From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | pg_receivewal starting position |
Date: | 2021-07-27 05:50:39 |
Message-ID: | 18708360.4lzOvYHigE@aivenronan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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'd be happy to implement any of that if we agree.
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-07-27 05:58:32 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
Previous Message | Andrey V. Lepikhov | 2021-07-27 05:34:30 | Re: Removing unneeded self joins |