Re: Improve documentation for pg_upgrade, standbys and rsync

[Robert Haas]

On Mon, Jul 26, 2021 at 3:11 PM Stephen Frost  wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > Thanks for looking at this!
>
> Sure.  Thanks for working on it!

Stephen, do you intend to do something about this patch in terms of
getting it committed? You're the only reviewer but haven't responded
to the thread for more than 5 months.

I don't feel that I know this area of the documentation well enough to
feel comfortable passing judgement on whether this change is an
improvement or not. However I do feel somewhat uncomfortable with
this:

-   
-Prepare for standby server upgrades
-
-
- If you are upgrading standby servers using methods outlined in
section , verify that the old standby
- servers are caught up by running pg_controldata
- against the old primary and standby clusters.  Verify that the
- Latest checkpoint location values match in all clusters.
- (There will be a mismatch if old standby servers were shut down
- before the old primary or if the old standby servers are still running.)
- Also, make sure wal_level is not set to
- minimal in the
postgresql.conf file on the
- new primary cluster.
-
-   

Right now, we say that you should stop the standby servers and then
prepared for standby server upgrades. With this patch, we say that you
should first prepare for standby server upgrades, and then stop the
standby servers. But the last part of the text about preparing for
standby server upgrades now mentions things to be done after carrying
out the next step where the servers are actually stopped. That seems
confusing. Perhaps we need two separate steps here, one to be
performed before stopping both servers and the other after.

Also, let me express my general terror at the idea of anyone actually
using this procedure.

Regards,

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Re: MacPorts xsltproc is very slow?

[Robert Haas]

On Fri, Mar 2, 2018 at 3:34 PM, Thomas Munro
 wrote:
> I think we should complain to the MacPorts packager about the
> namespace vs non-namespace stuff being possibly confused in the
> packages.

Any ideas about a workaround for the meantime?  Having to wait half an
hour for the documentation to build is pretty annoying.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: MacPorts xsltproc is very slow?

[Robert Haas]

On Sun, Nov 26, 2017 at 5:03 PM, Thomas Munro
 wrote:
> That got me wondering... why does the Apple xsltproc in /usr/bin work
> then?  Where is it even getting docbook-xsl from?  I ran it with
> --profile and http://docbook.sourceforge.net instead of file:// URLs,
> and I could see outgoing connections with netstat.  It believe that's
> because it doesn't find it locally in /etc/xml/catalog, whereas the
> MacPorts xsltproc looks in /opt/locl/etc/xml/catalog where it has been
> listed by the docbook-xsl package.
>
> So one solution is simply to uninstall the docbook-xsl package.  That
> gets me back to fast documentation builds!

For me, the documentation build fails without docbook-xsl.  I wonder
why it works for you.

It also fails for me if I follow the instructions in the documentation:

If you use MacPorts, the following will get you set up:

sudo port install docbook-xml-4.2 docbook-xsl fop


I have to also 'port install libxslt'.  Otherwise, /usr/bin/xsltproc
is used, and it won't use files installed by MacPorts packages.

And then it takes, like you reported originally, an insanely long time.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company