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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers