Thread: doc patch: wrong descriptions for dropping replication slots
Dear hackers,
While considering another thread, I found the $SUBJECT. Attached patch fixes it.
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.
I think all supported versions have the same issue, attached one is for master.
Thanks Hou for confirming the issue.
[1]: https://www.postgresql.org/message-id/CAMsr%2BYGjZRqo-boCF9z5Bc1WZ_10RjMLtNSTsaa%3DkkE9_GmTag%40mail.gmail.com
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Attachment
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
RE: doc patch: wrong descriptions for dropping replication slots
From
"Hayato Kuroda (Fujitsu)"
Date:
Dear Fujii-san, > Why was this restriction removed? If there was a past discussion about it, > could you share the details? More properly, pg_drop_replication_slot() has been introduced since PG9.4, and old documents did not have the description. The description has been added while developing PG10 and kept till now. The restriction was introduced in v1 patch and removed in v2 patch [1]. ISTM there were no discussions in the thread. I tried to find the initial design of the function, but I could not find. > 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. I think the description was accidentally retained. As I said above, replication slot can be dropped from anywhere since PG9.4. Andres pointed out the description was not needed in post-commit review [2]. Craig posted a follow-up patch [3], but it was missed. [1]: https://www.postgresql.org/message-id/CAMsr%2BYEsrUf0sq9RtK7cy2wM7%2BpUQQ22LzPU-FzVOBL7PROwhg%40mail.gmail.com [2]: https://www.postgresql.org/message-id/20170328152238.h3ikwwsl5kbqq6nk%40alap3.anarazel.de [3]: https://www.postgresql.org/message-id/CAMsr%2BYFdRMxFNvofWyBJ1zdhFgEBHZf%3D0TWrt9Z3QRSWLepvgQ%40mail.gmail.com Best regards, Hayato Kuroda FUJITSU LIMITED
On 2025/03/19 11:07, Hayato Kuroda (Fujitsu) wrote:
> Dear Fujii-san,
>
>> Why was this restriction removed? If there was a past discussion about it,
>> could you share the details?
>
> More properly, pg_drop_replication_slot() has been introduced since PG9.4, and old
> documents did not have the description. The description has been added while
> developing PG10 and kept till now.
>
> The restriction was introduced in v1 patch and removed in v2 patch [1].
> ISTM there were no discussions in the thread. I tried to find the initial design
> of the function, but I could not find.
>
>> 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.
>
> I think the description was accidentally retained. As I said above, replication slot
> can be dropped from anywhere since PG9.4. Andres pointed out the description was
> not needed in post-commit review [2]. Craig posted a follow-up patch [3], but it was
> missed.
Thanks for the clarification! I agree that the description is incorrect
and should be removed.
Unless there are any objections, I plan to push your patch with
the following commit message and back-patch it to all supported versions.
-------
doc: Remove incorrect description about dropping replication slots.
pg_drop_replication_slot() can drop replication slots created on
a different database than the one where it is executed. This behavior
has been in place since PostgreSQL 9.4, when pg_drop_replication_slot()
was introduced.
However, commit ff539d mistakenly added the following incorrect
description in the documentation:
For logical slots, this must be called when connected to
the same database the slot was created on.
This commit removes that incorrect statement. A similar mistake was
also present in the documentation for the DROP_REPLICATION_SLOT
command, which has now been corrected as well.
Back-patch to all supported versions.
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/OSCPR01MB14966C6BE304B5BB2E58D4009F5DE2@OSCPR01MB14966.jpnprd01.prod.outlook.com
Backpatch-through: 13
-------
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
RE: doc patch: wrong descriptions for dropping replication slots
From
"Hayato Kuroda (Fujitsu)"
Date:
Dear Fujii-san, > Unless there are any objections, I plan to push your patch with > the following commit message and back-patch it to all supported versions. ... Thanks for updating the commit message. LGTM. Best regards, Hayato Kuroda FUJITSU LIMITED
On 2025/03/21 10:07, Hayato Kuroda (Fujitsu) wrote: > Dear Fujii-san, > >> Unless there are any objections, I plan to push your patch with >> the following commit message and back-patch it to all supported versions. > ... > > Thanks for updating the commit message. LGTM. I've committed the patch with that message. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION