On 10/29/18 11:26 AM, Andres Freund wrote:
>
> On October 29, 2018 1:31:56 PM EDT, "Joshua D. Drake" <jd@commandprompt.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
atstart...
Well, this is the recovery.conf:
standby_mode = 'on'
recovery_target = 'immediate'
primary_slot_name = 'testing_db01'
primary_conninfo = 'user=replication
passfile=/var/lib/postgresql/.pgpass host=db01 port=5432 sslmode=prefer
sslcompression=1 krbsrvname=postgres target_session_attrs=any'
recovery_target_action = 'promote'
The machine came up clean and the only reason I noticed the problem is
that it ran out of disk space. I cleared enough disk space to get it to
come up again and noticed that there were replication slots that were
identical to the primary.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
*** A fault and talent of mine is to tell it exactly how it is. ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
***** Unless otherwise stated, opinions are my own. *****
