Horton

Re: pg_recvlogical requires -d but not described on the documentation

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread View on postgr.es
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-18T16:37:19Z
Lists: pgsql-hackers 

On 2025/03/18 18:17, Hayato Kuroda (Fujitsu) wrote:
> Dear Fujii-san, David,
> 
>>> BTW, I'm curious why --dbname isn't required for the --drop-slot action.
>>
>> I'm analyzing around here...
>>
> 
> Actually, replication slots can be dropped from another database where it created,
> or even from the streaming replication connection.
> I forked the new thread which fixes the description [1].
> 
> Based on the fact, there are two approaches to fix:
> 
> 1. Fix not to raise fatal error like:


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.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Commits

  1. Allow pg_recvlogical --drop-slot to work without --dbname.

  2. doc: Clarify required options for each action in pg_recvlogical.

  3. Refactor replication connection code of various pg_basebackup utilities.