Re: pg_recvlogical requires -d but not described on the documentation
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
"David G. Johnston" <david.g.johnston@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
'vignesh C' <vignesh21@gmail.com>
Date: 2025-03-19T17:51:43Z
Lists: pgsql-hackers
On 2025/03/19 11:32, Hayato Kuroda (Fujitsu) wrote: > Dear Fujii-san, > >> It looks like commit 0c013e08cfb introduced a bug that causes "pg_recvlogical >> --drop-slot" >> without --dbname to check whether it's connected to a specific database and fail >> if it's not. >> >> This commit was added before 9.5, while pg_recvlogical was introduced in 9.4. On >> my env, >> "pg_recvlogical --drop-slot" without --dbname worked as expected in 9.4 but >> started >> failing in 9.5 or later. >> >> So, I think the proper fix is to avoid raising a fatal error even when not connected >> to >> a specific database in --drop-slot action. > > +1. I created patch to fix it. 0001 was completely same as you did. Thanks for the patch! It looks good to me. I'm considering whether to back-patch these changes to older versions. Since pg_recvlogical --drop-slot worked without --dbname in 9.4 but started failing unintentionally in 9.5, it could be considered a bug. However, this behavior has existed for a long time without complaints or bug reports, and there was no clear documentation stating that --drop-slot should work without --dbname. Given this, I think that also we could treat it as not a bug and apply the change only to the master branch. What do you think should we back-patch it as a bug fix or apply it only to master? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
Allow pg_recvlogical --drop-slot to work without --dbname.
- c68100aa4313 18.0 landed
-
doc: Clarify required options for each action in pg_recvlogical.
- dfc13428a908 18.0 landed
-
Refactor replication connection code of various pg_basebackup utilities.
- 0c013e08cfbe 9.5.0 cited