Date: Tue, 5 Apr 2022 14:59:53 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Laurenz Albe <laurenz.albe@cybertec.at>,
	pgsql-docs@lists.postgresql.org
Subject: Re: Improve documentation for pg_upgrade, standbys and rsync
Message-ID: <YkyRqX2Rlz4sN/Tj@momjian.us>
References: <22f129004bb66cd91e1dfd3345a9787f5039f3ae.camel@cybertec.at>
 <20210519143135.GI20766@tamriel.snowman.net>
 <c176f23cdde4d4ff0010b5e7a517c1b371500279.camel@cybertec.at>
 <20210716131744.GA20766@tamriel.snowman.net>
 <a1a9cf4ebc8c674f4165af376c522f52ab02a3f6.camel@cybertec.at>
 <20210726191126.GW20766@tamriel.snowman.net>
 <CA+TgmobJBezsjg1afKK3jQCz75RX_Fankf65os=0Cuh93oFjPQ@mail.gmail.com>
 <20220405171038.GU10577@tamriel.snowman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220405171038.GU10577@tamriel.snowman.net>
Archived-At: 
 <https://www.postgresql.org/message-id/YkyRqX2Rlz4sN/Tj%40momjian.us>
Precedence: bulk

On Tue, Apr  5, 2022 at 01:10:38PM -0400, Stephen Frost wrote:
> To be more explicit though- we should write a tool to do this.  We
> shouldn't try to document a way to do it because it's hard to get right.
> While rsync is very capable, what's needed to really do this goes beyond
> what we could reasonably put into any rsync command or really even into
> a documented procedure.  I get that we already have it documented (and
> I'll note that doing so was against my recommendation..) and that some
> folks (likely those who follow this mailing list) have had success using
> it, but I'd really rather we just take it out and put it on a wiki
> somewhere as a "we need a tool that does this stuff" and hope that
> someone finds time to write one.

Well, I think pg_upgrade needs a tool, let alone for standby upgrades,
but 13 years in, no one has written one, so I am not holding my breath. 
Also, we need to document the procedure _somewhere_ --- if we don't the
only procedure is embedded in a tool. and that seems even worse than
what we have now.

> It should really be both- things to do on the primary ahead of time
> (truncate all unlogged tables, make sure there aren't any orphaned
> temporary tables, etc), and then things to do on the replicas after
> shutting the primary down (basically, make sure they are fully caught up
> with where the primary was at shutdown).  I tried to explain that in my
> prior email but perhaps didn't do a very good job.
> 
> > Also, let me express my general terror at the idea of anyone actually
> > using this procedure.
> 
> I mean, yeah, I agree.

I thought that was true for pg_upgrade in general?  ;-)

Seems like a pull up your sleeves and hold your nose --- I am good at
those tasks.  ;-)  Should I work on this?  Tangentially, I see that my
old macros fastgetattr and heap_getattr have finally been retired by
commit e27f4ee0a7.  :-)

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson