Re: pg_recvlogical requires -d but not described on the documentation
От | Fujii Masao |
---|---|
Тема | Re: pg_recvlogical requires -d but not described on the documentation |
Дата | |
Msg-id | de7e9c5f-dbaf-48b0-8a65-060615c1e9dd@oss.nttdata.com обсуждение исходный текст |
Ответ на | RE: pg_recvlogical requires -d but not described on the documentation ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: pg_recvlogical requires -d but not described on the documentation
|
Список | 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
В списке pgsql-hackers по дате отправления: