From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | A proposal to force-drop replication slots to make disabling async/sync standbys or logical replication faster in production environments |
Date: | 2022-06-09 05:37:15 |
Message-ID: | CALj2ACXnCbCHSS2RS3u4RBNpEPEwKMTrPigmDj+g3wV0omAmZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Currently postgres doesn't allow dropping a replication slot that's active
[1]. This can make certain operations more time-consuming or stuck in
production environments. These operations are - disable async/sync standbys
and disable logical replication that require the postgres running on
standby or the subscriber to go down. If stopping postgres server takes
time, the VM or container will have to be killed forcefully which can take
a considerable amount of time as there are many layers in between.
How about we provide a function to force-drop a replication slot? All other
things such as stopping postgres and gracefully unprovisioning VM etc. can
be taken care of in the background. This force-drop function will also have
to ensure that the walsender that's active for the replication slot is
terminated gracefully without letting postmaster restart the other backends
(right now if a wal sender is exited/terminated, the postmaster restarts
all other backends too). The main advantage of the force-drop function is
that the disable operations can be quicker and there is no down time/crash
on the primary/source server.
Thoughts?
[1] ERROR: replication slot "foo" is active for PID 2598155
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-06-09 05:39:55 | Re: Collation version tracking for macOS |
Previous Message | Jeremy Schneider | 2022-06-09 05:24:49 | Re: Collation version tracking for macOS |