Hi,
On 2019-01-11 16:52:42 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15591
> Logged by: Jeff Janes
> Email address: jeff.janes@gmail.com
> PostgreSQL version: 11.1
> Operating system: all
> Description:
>
> When you invoke pg_receivewal using --slot to give it the name of an
> existing slot which has WAL reserved, and -D pointing to an empty directory,
> it fast-forwards the slot's LSN reservation to the beginning of the most
> recent WAL file on the server, and starts streaming from there. Rather than
> streaming from the LSN reservation point.
I don't think there's a bug here. A slot just reserves WAL on the
primary, it's not a marker of how much data the standby actually
has. It'd be a pretty unsuitable place to store the point up to where
the standby has received data, because it's necessarily going to lag
behind that. The slot's LSN is the most pessimistic assumption about
what's needed, whereas the receiving side should have accurate
knowledge.
> Does this not utterly destroy the main point of using slots? If I didn't
> want to ensure a gapless WAL stream, why use slots in the first place?
So the upstream server doesn't drop WAL that a standby (or something
like that) still needs? It's pretty rare to randomly start to stream to
a differnt place.
Greetings,
Andres Freund
