Re: Add docs stub for recovery.conf

From: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add docs stub for recovery.conf
Date: 2020-11-30 02:11:04
Message-ID: CAGRY4nzgR4pBUyzARxsJsZ=4zUcEEg_9O+0TbULQ+HS+rErRTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 14, 2020 at 1:42 AM Bruce Momjian <bruce(at)momjian(dot)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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-11-30 02:12:13 Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Previous Message Masahiko Sawada 2020-11-30 01:43:09 Re: autovac issue with large number of tables