Horton

Re: replication_slots usability issue

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: "Joshua D. Drake" <jd@commandprompt.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-29T19:02:18Z
Lists: pgsql-hackers 
On 2018-Oct-29, Joshua D. Drake wrote:

> -Hackers,
> 
> 
> Working on 9.6 today (unsure if fixed in newer versions). Had an issue where
> the wal was 280G despite max_wal_size being 8G. Found out there were stale
> replication slots from a recent base backup. I went to drop the replication
> slots and found that since the wal_level was set to minimal vs replica or
> higher, I couldn't drop the replication slot. Clearly that makes sense for
> creating a replication slot but it seems like an artificial limitation for
> dropping them.

This sounds closely related to
https://www.postgresql.org/message-id/20180508143725.mn3ivlyvgpul6ovr%40alvherre.pgsql
(commit a1f680d962ff) wherein we made it possible to drop a slot in
single-user mode.

Seems worth fixing.  Send a patch?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Fix copy-paste error in errhint() introduced in 691d79a07933.

  2. Lower error level from PANIC to FATAL when restoring slots at startup

  3. Fix error message typo introduced 691d79a07933.

  4. Disallow starting server with insufficient wal_level for existing slot.

  5. Allow replication slots to be dropped in single-user mode