From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, 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: | 2021-12-02 03:02:08 |
Message-ID: | CALj2ACUdwnEQm8jf=AY=VU2Z-2AL1yHNn86viCeivTz25ygnrw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 2, 2021 at 4:22 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2021-11-30 18:43:23 +0000, Bossart, Nathan wrote:
> > On 11/30/21, 6:14 AM, "Peter Eisentraut" <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> > > On 23.11.21 06:09, Bharath Rupireddy wrote:
> > >> The replication slots data is stored in binary format on the disk under
> > >> the pg_replslot/<<slot_name>> directory which isn't human readable. If
> > >> the server is crashed/down (for whatever reasons) and unable to come up,
> > >> currently there's no way for the user/admin/developer to know what were
> > >> all the replication slots available at the time of server crash/down to
> > >> figure out what's the restart lsn, xid, two phase info or types of slots
> > >> etc.
> > >
> > > What do you need that for? You can't do anything with a replication
> > > slot while the server is down.
>
> Yes, I don't think there's sufficient need for this.
Thanks. The idea of the pg_replslotdata is emanated from the real-time
working experience with the customer issues and answering some of
their questions. Given the fact that replication slots are used in
almost every major production servers, and they are likely to cause
problems, postgres having a core tool like pg_replslotdata to
interpret the replication slot info without contacting the server,
will definitely be useful for all the other postgres vendors out
there. Having some important tool in the core, can avoid duplicate
efforts.
> > 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.
Having said that, other hackers may have better thoughts.
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-12-02 03:12:25 | Re: pg_get_publication_tables() output duplicate relid |
Previous Message | Greg Nancarrow | 2021-12-02 02:48:34 | Re: Data is copied twice when specifying both child and parent table in publication |