From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org,"Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: replication_slots usability issue |
Date: | 2018-10-29 18:26:56 |
Message-ID: | 835C001D-7F0B-4C90-BFB3-5D6EE5E71A21@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On October 29, 2018 1:31:56 PM EDT, "Joshua D. Drake" <jd(at)commandprompt(dot)com> 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.
Uh, huh? How did you manage to start a server with existing slots with that configuration? It should have errored out at start...
Andres
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-10-29 18:46:15 | Re: date_trunc() in a specific time zone |
Previous Message | Joshua D. Drake | 2018-10-29 17:31:56 | replication_slots usability issue |