On 2025/03/18 17:46, Hayato Kuroda (Fujitsu) wrote:
Dear hackers,
While considering another thread, I found the $SUBJECT. Attached patch fixes it.
Thanks for the patch!
Documentation says:
```
pg_drop_replication_slot ( slot_name name ) → void
Drops the physical or logical replication slot named slot_name. Same as
replication protocol command DROP_REPLICATION_SLOT.
For logical slots, this must be called while connected to the same database the
slot was created on.
```
But this is not correct. Backend processes which connect to other databases
can drop the logical slot:
```
postgres=# SELECT * FROM pg_create_logical_replication_slot('test',
'test_decoding');
slot_name | lsn
-----------+-----------
test | 0/1CA6A18
(1 row)
postgres=# \c tests
You are now connected to database "tests" as user "postgres".
tests=# SELECT * FROM pg_drop_replication_slot('test');
pg_drop_replication_slot
--------------------------
(1 row)
```
IIUC, the description was added by ff539d. The initial version [1] seemed to
have
the restriction, it was removed now but the description retained.
Why was this restriction removed? If there was a past discussion about it,
could you share the details?
Since it's generally expected that a session in one database shouldn't
be able to drop objects in another, I'm wondering if removing this
restriction was intentional or possibly a bug.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
