Re: Add docs stub for recovery.conf - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Add docs stub for recovery.conf
Date
Msg-id CAGRY4nzgR4pBUyzARxsJsZ=4zUcEEg_9O+0TbULQ+HS+rErRTQ@mail.gmail.com
Whole thread Raw
In response to Re: Add docs stub for recovery.conf  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Add docs stub for recovery.conf  (Stephen Frost <sfrost@snowman.net>)
Re: Add docs stub for recovery.conf  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Sat, Nov 14, 2020 at 1:42 AM Bruce Momjian <bruce@momjian.us> wrote:

Clearly we have need for documenting these renamings somewhere. We were
going to go with a simple URL redirect and a "tip" for
default/pre-installed roles, but I like the idea of doing something more
wholistic that covers all of our recent renaming cases.  Let's get
buy-in from that, and then someone can work on a patch.

Is there anything further I can do to address this specific documentation issue?

Can I get you to consider the user experience arising from the current docs - try using the docs to find out how to set up a standby?

I'm not prepared to expand the scope of this to do a major review of all past renamings and changes without a very clear agreement about how that should be implemented in the docs and how that will address all the relevant UX issues - vanishing terms from indexes and docs without x-refs/see-alsos, vanishing URLs endpoints for public links, vanishing next-version links in www docs.

I didn't raise this for discussion before I submitted a patch because I thought it was such an obvious no-brainer that a simple patch to address an obviously confusing aspect of the docs after the recovery.conf removal would be uncontroversial. Anyway, as I've noted, these things often get ignored until there is a patch to argue about.

Can we please just address this docs issue? If you don't like my solution can you please supply a patch that you feel addresses the problem? Or clearly state that you don't think there is a problem, and do so in a way that actually addresses the specific points I have raised about what's wrong with the status quo?

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: autovac issue with large number of tables
Next
From: Fujii Masao
Date:
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module