Re: Need Force flag for pg_drop_replication_slot()

So, here's an example of why it's hard to give our users a workaround.

cio=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid |
database | active | xmin | catalog_xmin | restart_lsn
-----------------------------------------+--------+-----------+--------+----------+--------+------+--------------+-------------
bdr_24577_6147720645156311471_1_26507__ | bdr | logical | 24577 |
cio | t | | 906 | 0/1C4F410
(1 row)

cio=# select
pg_drop_replication_slot('bdr_24577_6147720645156311471_1_26507__');
ERROR: replication slot "bdr_24577_6147720645156311471_1_26507__" is
already active
cio=# select * from pg_stat_replication;
-[ RECORD 1 ]----+-------------------------------------------
pid | 28481
usesysid | 10
usename | postgres
application_name | bdr (6147720645156311471,1,26507,):receive
client_addr | 172.17.0.11
client_hostname |
client_port | 44583
backend_start | 2015-05-29 18:10:34.601796+00
backend_xmin |
state | streaming
sent_location | 0/1C4F448
write_location | 0/1C4F448
flush_location | 0/1C4F448
replay_location | 0/1C4F448
sync_priority | 0
sync_state | async

Now, BDR is good because it sets an application_name which lets me
figure out what's using the replication slot. But that's by no means
required; other LC plug-ins, I expect, do not do so. So there's no way
for the user to figure out which replication connection relates to which
slots, as far as I can tell.

In this test, it's easy because there's only one replication connection
and one slot. But imagine the case of 14 replication connections with
their own slots. How could you possibly figure out which one was the
laggy one?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com