Re: doc patch: wrong descriptions for dropping replication slots

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