Re: pg_replslotdata - a tool for displaying replication slot information

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_replslotdata - a tool for displaying replication slot information
Date: 2022-01-15 08:50:12
Message-ID: 20220115085012.cqr44n63mpumyodm@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Mon, Dec 06, 2021 at 07:16:12PM +0000, Bossart, Nathan wrote:
> On 12/5/21, 11:10 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> > On Thu, Dec 02, 2021 at 08:32:08AM +0530, Bharath Rupireddy wrote:
> >> On Thu, Dec 2, 2021 at 4:22 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >>>> I don't have any other compelling use- cases at the moment, but I will say
> >>>> that it is typically nice from an administrative standpoint to be able to
> >>>> inspect things like this without logging into a running server.
> >>>
> >>> Weighed against the cost of maintaining (including documentation) a separate
> >>> tool this doesn't seem sufficient reason.
> >>
> >> IMHO, this shouldn't be a reason to not get something useful (useful
> >> IMO and few others in this thread) into the core. The maintenance of
> >> the tools generally is low compared to the core server features once
> >> they get reviewed and committed.
> >
> > Well, a bit less maintenance is always better than more maintenance.
> > An extra cost that you may be missing is related to the translation of
> > the documentation, as well as the translation of any new strings this
> > would require. FWIW, I don't directly see a use for this tool that
> > could not be solved with an online server.
> Bharath, perhaps you should maintain this outside of core PostgreSQL
> for now. If some compelling use-cases ever surface that make it seem
> worth the added maintenance burden, this thread could probably be
> revisited.

Ironically, the patch is currently failing due to translation problem:
[19:12:28.179] su postgres -c "make -s -j${BUILD_JOBS} world-bin"
[19:12:44.270] make[3]: *** No rule to make target 'po/cs.po', needed by 'po/'. Stop.
[19:12:44.270] make[2]: *** [Makefile:44: all-pg_replslotdata-recurse] Error 2
[19:12:44.270] make[2]: *** Waiting for unfinished jobs....
[19:12:44.499] make[1]: *** [Makefile:42: all-bin-recurse] Error 2
[19:12:44.499] make: *** [GNUmakefile:21: world-bin-src-recurse] Error 2

Looking at the thread, I see support from 3 people:

- Bharath
- Japin
- Satyanarayana

while 3 committers think that the extra maintenance effort isn't worth the

- Peter E.
- Andres
- Michael

and a +0.5 from Nathan IIUC.

I also personally don't think that this worth the maintenance effort. This
tool being entirely client side, there's no problem with maintaining it on a
separate repository, as mentioned by Nathan, including using it on the cloud
providers that provides access to at least the data file. Another pro of the
external repo is that the tool can be made available immediately and for older

Since 3 committers voted against it I think that the patch should be closed
as "Rejected". I will do that in a few days unless there's some compelling
objection by then.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2022-01-15 09:00:11 Re: psql - add SHOW_ALL_RESULTS option
Previous Message Bharath Rupireddy 2022-01-15 08:34:12 Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work