Add docs stub for recovery.conf

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
On Fri, Nov 13, 2020 at 01:27:34PM +0800, Craig Ringer wrote:

> On Fri, Nov 13, 2020 at 11:50 AM Bruce Momjian <[hidden email]> wrote:
>  
>
>     > So you are saying you don't think you are getting sufficient thought
>     > into your proposal, and getting just a reflex?  Just because we don't
>     > agree with you don't mean we didn't think about it.  In fact, we have
>     > thought about it a lot, which is evident from the URL I sent you
>     > already.
>
>
> I am mostly trying to say that I don't think the issues I raised were actually
> addressed in the proposed alternatives. I put in a fair bit of effort to
> clearly set out the problem that this is meant to solve, and was frustrated to
> perceive the response as "yeah, nah, lets just do this other thing that only
> addresses one part of the original issue." It wasn't clear why my proposal
> appeared to be being rejected. Perhaps I didn't fully grasp the context of the
> linked discussion.

I think the big problem, and I have seen this repeatedly, is showing up
with a patch without discussing whether people actually want the
feature.  I know it is a doc issue, but our TODO list has the order as:

        Desirability -> Design -> Implement -> Test -> Review -> Commit

and there is a reason for that.  When you appear with a patch, you are
already far down the steps, and you have to back up to explain why it is
useful.

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.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

David G Johnston
On Fri, Nov 13, 2020 at 10:42 AM Bruce Momjian <[hidden email]> wrote:
I think the big problem, and I have seen this repeatedly, is showing up
with a patch without discussing whether people actually want the
feature.  I know it is a doc issue, but our TODO list has the order as:

        Desirability -> Design -> Implement -> Test -> Review -> Commit 

and there is a reason for that.  When you appear with a patch, you are
already far down the steps, and you have to back up to explain why it is
useful.

That process is designed to prevent people from being exposed to wasted effort and hard feelings.  The choice to follow it individually, instead of collectively, doesn't diminish the value of the end result.

I generally agree with Craig's proposed solution here.  It doesn't add any cognitive load to new users as they will not see the obsolete features appendix in the normal course of their reading.

To the particular point regarding renaming features - this situation is not an instance of a rename but rather a feature removal.  To blindly apply the reasoning and decision made for renaming to removal is not reasonable.  From that observation (and the commentary below) extends the conclusion that this appendix shouldn't include renaming.

On the point of renaming, my suggestion would be to have the documentation directory provide a file of all renaming for which redirects should be performed.  pgweb would source that file and actually establish the redirects on the main website.  Comments in the file can describe to a curious user why the name change was needed.  Though that honestly seems a bit overkill; for rename, the content as a whole still exists and a comment therein can talk about the renaming.  Users of the public website would still get the benefit of redirects, and there isn't any practical reason for people building documentation from source to want to establish such redirects even if they were provided the data in the form of the aforementioned file.

I believe there is probably room for more discussion regarding the value of providing a limited view of history in the publicly facing documentation but that seems outside the scope of this patch.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Craig Ringer-5


On Sun, Nov 15, 2020 at 1:49 PM David G. Johnston <[hidden email]> wrote:
On Fri, Nov 13, 2020 at 10:42 AM Bruce Momjian <[hidden email]> wrote:
I think the big problem, and I have seen this repeatedly, is showing up
with a patch without discussing whether people actually want the
feature.  I know it is a doc issue, but our TODO list has the order as:

        Desirability -> Design -> Implement -> Test -> Review -> Commit 

and there is a reason for that.  When you appear with a patch, you are
already far down the steps, and you have to back up to explain why it is
useful.

That process is designed to prevent people from being exposed to wasted effort and hard feelings.  The choice to follow it individually, instead of collectively, doesn't diminish the value of the end result.

Frankly, it's also kind of a catch-22. Because often proposals for changes or discussion get ignored until there's a patch, or the response is along the lines of "show us a patch so we can try it and get a solid idea of what this will do."

For major engineering changes, yes, discuss first. For small stuff, if you don't want to get ignored, open with a patch.

On the point of renaming, my suggestion would be to have the documentation directory provide a file of all renaming for which redirects should be performed.  pgweb would source that file and actually establish the redirects on the main website.  Comments in the file can describe to a curious user why the name change was needed.  Though that honestly seems a bit overkill; for rename, the content as a whole still exists and a comment therein can talk about the renaming.  Users of the public website would still get the benefit of redirects, and there isn't any practical reason for people building documentation from source to want to establish such redirects even if they were provided the data in the form of the aforementioned file.

Agreed, there's no need to keep heading redirects in the source-built docs. So if we're happy to maintain that on the website, in a way that makes /current/ links work *and* following links from a /11/ docs page that has vanished in pg12 to the right new place via the version navigation links, that's sufficient for topic-heading renames.

We should, however, carry information about removals and renames in the source-built docs to the extent that we have appropriate "see also" index entries and useful information somewhere in the docs for people who are upgrading. It just doesn't have to retain the same subject heading.
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Craig Ringer-5
In reply to this post by Bruce Momjian
On Sat, Nov 14, 2020 at 1:42 AM Bruce Momjian <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Stephen Frost
Greetings,

* Craig Ringer ([hidden email]) wrote:

> On Sat, Nov 14, 2020 at 1:42 AM Bruce Momjian <[hidden email]> 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?
For my 2c, at least, I'm in favor of making some kind of change here to
make things better for users.  I tried to figure out a way using the
features we have easily available in pgweb, but I tend to agree with
Craig that those just aren't enough for the more recent set of changes
that we've made.

> 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.

The past renamings haven't really been as much of an issue since the
redirects and such, imv anyway, have been sufficient to deal with them.

> 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?

While I understand not wanting to go back through and check for all
renamings, it seems like we should probably at least list out the ones
we know about pretty easily, if we're going to create a new section
specifically for those cases..?  Or do we think the current approach
works well enough for those other cases but just not for this one?

Think I listed this elsewhere but not seeing it on the thread so I'll
include it here anyway.  These are the current doc aliases:

catalog-pg-replication-slots.html <-> view-pg-replication-slots.html
pgxlogdump.html <-> pgwaldump.html
app-pgresetxlog.html <-> app-pgresetwal.html
legalnotice.html <-> LEGALNOTICE.html
app-pgreceivexlog.html <-> app-pgreceivewal.html

As relates to the specific patch, I don't think the comments line up
quite right (we can prevent a 404 from happening through other means,
but the point of the patch is really to give a deeper explanation of
what happened).  Also- wrt pg_basebackup, isn't that expected to support
older versions, and so we should document the behavior against older
versions..?

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
In reply to this post by Craig Ringer-5
On Mon, Nov 30, 2020 at 10:11:04AM +0800, Craig Ringer wrote:
> 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?

If we know there are X problems, and we fix one of them one way, then
later fix the rest another way, we have to undo the first fix.  If you
don't want to fix all X, then let's wait until someone does want to fix
them all.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

David G Johnston
On Mon, Nov 30, 2020 at 11:25 AM Bruce Momjian <[hidden email]> wrote:
On Mon, Nov 30, 2020 at 10:11:04AM +0800, Craig Ringer wrote:
> 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?

If we know there are X problems, and we fix one of them one way, then
later fix the rest another way, we have to undo the first fix.  If you
don't want to fix all X, then let's wait until someone does want to fix
them all.


IMO there is only the original problem with an acceptable solution presented that can be committed without downside.  If that has to be undone because someone else in the future decides on a different solution that happens to touch this too, fine, it can be changed again.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
On Mon, Nov 30, 2020 at 11:31:35AM -0700, David G. Johnston wrote:

> On Mon, Nov 30, 2020 at 11:25 AM Bruce Momjian <[hidden email]> wrote:
>
>     On Mon, Nov 30, 2020 at 10:11:04AM +0800, Craig Ringer wrote:
>     > 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?
>
>     If we know there are X problems, and we fix one of them one way, then
>     later fix the rest another way, we have to undo the first fix.  If you
>     don't want to fix all X, then let's wait until someone does want to fix
>     them all.
>
> IMO there is only the original problem with an acceptable solution presented
> that can be committed without downside.  If that has to be undone because
> someone else in the future decides on a different solution that happens to
> touch this too, fine, it can be changed again.

The downside is you end up with X-1 dummy sections just to allow for
references to old syntax, and you then have to find them all and remove
them when you implement the proper solution.  I have no intention of
applying such an X-1 fix.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

David G Johnston
On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian <[hidden email]> wrote:

The downside is you end up with X-1 dummy sections just to allow for
references to old syntax, and you then have to find them all and remove
them when you implement the proper solution.  I have no intention of
applying such an X-1 fix.


X = 2; seems like a strong objection for such a minor issue.  The status quo seems worse than that.

David J.
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Stephen Frost
Greetings,

* David G. Johnston ([hidden email]) wrote:
> On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian <[hidden email]> wrote:
> > The downside is you end up with X-1 dummy sections just to allow for
> > references to old syntax, and you then have to find them all and remove
> > them when you implement the proper solution.  I have no intention of
> > applying such an X-1 fix.
>
> X = 2; seems like a strong objection for such a minor issue.  The status
> quo seems worse than that.

I've been thinking about this and I think I'm on Craig and David's side-
having something cleaner, and clearer, than just http redirects and such
would be good for these cases and I don't think we are going to end up
with so many of them that it ends up becoming an issue.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
On Wed, Dec  2, 2020 at 02:47:13PM -0500, Stephen Frost wrote:

> Greetings,
>
> * David G. Johnston ([hidden email]) wrote:
> > On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian <[hidden email]> wrote:
> > > The downside is you end up with X-1 dummy sections just to allow for
> > > references to old syntax, and you then have to find them all and remove
> > > them when you implement the proper solution.  I have no intention of
> > > applying such an X-1 fix.
> >
> > X = 2; seems like a strong objection for such a minor issue.  The status
> > quo seems worse than that.
>
> I've been thinking about this and I think I'm on Craig and David's side-
> having something cleaner, and clearer, than just http redirects and such
> would be good for these cases and I don't think we are going to end up
> with so many of them that it ends up becoming an issue.

We were not going to use just redirects --- we were going to create a
page that had all the renames listed, with links to the new names.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Stephen Frost
Greetings,

* Bruce Momjian ([hidden email]) wrote:

> On Wed, Dec  2, 2020 at 02:47:13PM -0500, Stephen Frost wrote:
> > * David G. Johnston ([hidden email]) wrote:
> > > On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian <[hidden email]> wrote:
> > > > The downside is you end up with X-1 dummy sections just to allow for
> > > > references to old syntax, and you then have to find them all and remove
> > > > them when you implement the proper solution.  I have no intention of
> > > > applying such an X-1 fix.
> > >
> > > X = 2; seems like a strong objection for such a minor issue.  The status
> > > quo seems worse than that.
> >
> > I've been thinking about this and I think I'm on Craig and David's side-
> > having something cleaner, and clearer, than just http redirects and such
> > would be good for these cases and I don't think we are going to end up
> > with so many of them that it ends up becoming an issue.
>
> We were not going to use just redirects --- we were going to create a
> page that had all the renames listed, with links to the new names.
Maybe I'm the one who is confused here, but I thought there was
objection to adding a new section/page which covers these topics (which
is what Craig's original patch does)...?  If there isn't an objection to
that then it seems like we should move forward with it.

If I'm following correctly, maybe there was some idea that we should
have more things added to this section than just the recovery.conf bits,
and perhaps we should, but that could certainly be done later.  To be
clear though, I don't think we need to do this in all cases- the
existing flow for pg_xlogdump -> pg_waldump works pretty well.  Maybe we
add in a note here too if someone wants to but I don't think it's
strictly necessary for the 'simple' rename cases.

I also feel like that could be done once the section gets added, if
someone wants to.

Was there something else that I'm missing here in terms of what the
concern is regarding Craig's patch..?

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
On Wed, Dec  2, 2020 at 05:57:01PM -0500, Stephen Frost wrote:

> * Bruce Momjian ([hidden email]) wrote:
> > We were not going to use just redirects --- we were going to create a
> > page that had all the renames listed, with links to the new names.
>
> Maybe I'm the one who is confused here, but I thought there was
> objection to adding a new section/page which covers these topics (which
> is what Craig's original patch does)...?  If there isn't an objection to
> that then it seems like we should move forward with it.
>
> If I'm following correctly, maybe there was some idea that we should
> have more things added to this section than just the recovery.conf bits,
> and perhaps we should, but that could certainly be done later.  To be
> clear though, I don't think we need to do this in all cases- the
> existing flow for pg_xlogdump -> pg_waldump works pretty well.  Maybe we
> add in a note here too if someone wants to but I don't think it's
> strictly necessary for the 'simple' rename cases.
>
> I also feel like that could be done once the section gets added, if
> someone wants to.
>
> Was there something else that I'm missing here in terms of what the
> concern is regarding Craig's patch..?

I think the ideal solution is to create a section for all the rename
cases and do all the redirects to that page.  The page would list the
old and new name for each item, and would link to the section for each
new item.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

David G Johnston
On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian <[hidden email]> wrote:
I think the ideal solution is to create a section for all the rename
cases and do all the redirects to that page.  The page would list the
old and new name for each item, and would link to the section for each
new item.


Nothing prevents us from doing that for simple renames.  For me, this situation is not a simple rename and the proposed solution is appropriate for what it is - changing the implementation details of an existing feature.  We can do both - though the simple rename page doesn't seem particularly appealing at first glance.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Isaac Morland
On Wed, 2 Dec 2020 at 19:33, David G. Johnston <[hidden email]> wrote:
On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian <[hidden email]> wrote:
I think the ideal solution is to create a section for all the rename
cases and do all the redirects to that page.  The page would list the
old and new name for each item, and would link to the section for each
new item.


Nothing prevents us from doing that for simple renames.  For me, this situation is not a simple rename and the proposed solution is appropriate for what it is - changing the implementation details of an existing feature.  We can do both - though the simple rename page doesn't seem particularly appealing at first glance.

I for one do not like following a bookmark or link and then being redirected to a generic page that doesn't relate to the specific link I was following. What is being proposed here is not as bad as the usual, where all the old links simply turn into redirects to the homepage, but it's still disorienting. I would much rather each removed page be moved to an appendix (without renaming) and edited to briefly explain what happened to the page and provide links to the appropriate up-to-date page or pages.
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
On Wed, Dec  2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:

> On Wed, 2 Dec 2020 at 19:33, David G. Johnston <[hidden email]>
> wrote:
>
>     On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian <[hidden email]> wrote:
>
>         I think the ideal solution is to create a section for all the rename
>         cases and do all the redirects to that page.  The page would list the
>         old and new name for each item, and would link to the section for each
>         new item.
>
>
>
>     Nothing prevents us from doing that for simple renames.  For me, this
>     situation is not a simple rename and the proposed solution is appropriate
>     for what it is - changing the implementation details of an existing
>     feature.  We can do both - though the simple rename page doesn't seem
>     particularly appealing at first glance.
>
>
> I for one do not like following a bookmark or link and then being redirected to
> a generic page that doesn't relate to the specific link I was following. What
> is being proposed here is not as bad as the usual, where all the old links
> simply turn into redirects to the homepage, but it's still disorienting. I
> would much rather each removed page be moved to an appendix (without renaming)
> and edited to briefly explain what happened to the page and provide links to
> the appropriate up-to-date page or pages.

Yes, that is pretty much the same thing I was suggesting, except that
each rename has its own _original_ URL link, which I think is also
acceptable.  My desire is for these items to all exist in one place, and
an appendix of them seems fine.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Stephen Frost
Greetings,

* Bruce Momjian ([hidden email]) wrote:

> On Wed, Dec  2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:
> > On Wed, 2 Dec 2020 at 19:33, David G. Johnston <[hidden email]>
> > wrote:
> >
> >     On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian <[hidden email]> wrote:
> >
> >         I think the ideal solution is to create a section for all the rename
> >         cases and do all the redirects to that page.  The page would list the
> >         old and new name for each item, and would link to the section for each
> >         new item.
> >
> >
> >
> >     Nothing prevents us from doing that for simple renames.  For me, this
> >     situation is not a simple rename and the proposed solution is appropriate
> >     for what it is - changing the implementation details of an existing
> >     feature.  We can do both - though the simple rename page doesn't seem
> >     particularly appealing at first glance.
> >
> >
> > I for one do not like following a bookmark or link and then being redirected to
> > a generic page that doesn't relate to the specific link I was following. What
> > is being proposed here is not as bad as the usual, where all the old links
> > simply turn into redirects to the homepage, but it's still disorienting. I
> > would much rather each removed page be moved to an appendix (without renaming)
> > and edited to briefly explain what happened to the page and provide links to
> > the appropriate up-to-date page or pages.
>
> Yes, that is pretty much the same thing I was suggesting, except that
> each rename has its own _original_ URL link, which I think is also
> acceptable.  My desire is for these items to all exist in one place, and
> an appendix of them seems fine.
Alright, so, to try and move this forward I'll list out (again) the
renames that we have in pgweb:

catalog-pg-replication-slots.html <-> view-pg-replication-slots.html
pgxlogdump.html <-> pgwaldump.html
app-pgresetxlog.html <-> app-pgresetwal.html
app-pgreceivexlog.html <-> app-pgreceivewal.html

(excluding the 'legal notice' one)

Bruce, are you saying that we need to take Craig's patch and then add to
it entries for all of the above, effectively removing the need for the
web page aliases and redirects?  If that was done, would that be
sufficient to get this committed?  Are there other things that people
can think of off-hand that we should include, I think Craig might have
mentioned something else earlier on..?  I don't think we should require
that someone troll through everything that ever existed, just to be
clear, as we can always add to this later if other things come up.  If
that's the expectation though, then someone needs to say so, in which
case I'll assume it's status quo unless/until someone steps up to do
that.

Obviously, I'd then have to adjust the patch that I proposed for default
roles, or move forward with it as-is, depending on what we end up doing
here.  I dislike what feels like a state of limbo for this right now
though.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

David G Johnston
On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost <[hidden email]> wrote:
Obviously, I'd then have to adjust the patch that I proposed for default
roles, or move forward with it as-is, depending on what we end up doing
here.  I dislike what feels like a state of limbo for this right now
though.


We have a committer + 1 in favor of status quo - or at least requiring that a non-existing solution be created to move things forward. (Bruce, Daniel)
We have a committer + 3 that seem to agree that the proposed patch is acceptable as presented. (Stephen, Craig, Isaac, David J.)
Anyone wish to update the above observation?

Stephen, are you will to commit this with the support of the community members who have spoken up here?

David J.

Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Stephen Frost
Greetings,

* David G. Johnston ([hidden email]) wrote:

> On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost <[hidden email]> wrote:
> > Obviously, I'd then have to adjust the patch that I proposed for default
> > roles, or move forward with it as-is, depending on what we end up doing
> > here.  I dislike what feels like a state of limbo for this right now
> > though.
>
> We have a committer + 1 in favor of status quo - or at least requiring that
> a non-existing solution be created to move things forward. (Bruce, Daniel)
> We have a committer + 3 that seem to agree that the proposed patch is
> acceptable as presented. (Stephen, Craig, Isaac, David J.)
> Anyone wish to update the above observation?
>
> Stephen, are you will to commit this with the support of the community
> members who have spoken up here?
What I was hoping to achieve is consensus on a reasonably well bounded
solution.  I'm not going to push something that others are objecting to,
but if we can agree on the idea and what's needed for it to be
acceptable then I'm willing to work towards that, provided it doesn't
require going back 10 versions and looking at every single change.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add docs stub for recovery.conf

Bruce Momjian
In reply to this post by Stephen Frost
On Fri, Dec  4, 2020 at 02:00:23PM -0500, Stephen Frost wrote:

> * Bruce Momjian ([hidden email]) wrote:
> > Yes, that is pretty much the same thing I was suggesting, except that
> > each rename has its own _original_ URL link, which I think is also
> > acceptable.  My desire is for these items to all exist in one place, and
> > an appendix of them seems fine.
>
> Alright, so, to try and move this forward I'll list out (again) the
> renames that we have in pgweb:
>
> catalog-pg-replication-slots.html <-> view-pg-replication-slots.html
> pgxlogdump.html <-> pgwaldump.html
> app-pgresetxlog.html <-> app-pgresetwal.html
> app-pgreceivexlog.html <-> app-pgreceivewal.html
>
> (excluding the 'legal notice' one)
>
> Bruce, are you saying that we need to take Craig's patch and then add to
> it entries for all of the above, effectively removing the need for the
> web page aliases and redirects?  If that was done, would that be

Yes, I think putting the compatibility section headings in our main
documentation flow will make it too hard to read and cause unnecessary
complexity, but if we have a separate section for them, adding the
section headings seems fine.  This way, we don't have to add a redirect
every time we add a new entry.

> sufficient to get this committed?  Are there other things that people
> can think of off-hand that we should include, I think Craig might have
> mentioned something else earlier on..?  I don't think we should require
> that someone troll through everything that ever existed, just to be
> clear, as we can always add to this later if other things come up.  If
> that's the expectation though, then someone needs to say so, in which
> case I'll assume it's status quo unless/until someone steps up to do
> that.

Agreed.  I just wanted something that could scale going forward, and be
easily identified as compatibility, so maybe one day we can remove them.
However, if they are in a separate section, we might never do that.

--
  Bruce Momjian  <[hidden email]>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee



123