Re: BUG #15591: pg_receivewal does not honor replication slots
От | Andres Freund |
---|---|
Тема | Re: BUG #15591: pg_receivewal does not honor replication slots |
Дата | |
Msg-id | 20190111185057.eufs2slfckkncij5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | BUG #15591: pg_receivewal does not honor replication slots (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15591: pg_receivewal does not honor replication slots
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: