On Thu, Dec 2, 2021 at 4:22 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2021-11-30 18:43:23 +0000, Bossart, Nathan wrote: > > On 11/30/21, 6:14 AM, "Peter Eisentraut" > > <peter.eisentr...@enterprisedb.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.
