From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | jeff(dot)janes(at)gmail(dot)com |
Subject: | BUG #15591: pg_receivewal does not honor replication slots |
Date: | 2019-01-11 16:52:42 |
Message-ID: | 15591-3d988c14166018a6@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 15591
Logged by: Jeff Janes
Email address: jeff(dot)janes(at)gmail(dot)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.
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?
I've tested in v11, but I think it is across all versions.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-01-11 17:24:27 | Re: BUG #15590: crosstab_hash unable to work with modified types (CreateTupleDescCopy returning dropped attributes?) |
Previous Message | PG Bug reporting form | 2019-01-11 15:25:56 | BUG #15590: crosstab_hash unable to work with modified types (CreateTupleDescCopy returning dropped attributes?) |