| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-docs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Improve documentation for pg_upgrade, standbys and rsync |
| Date: | 2022-04-05 18:59:53 |
| Message-ID: | YkyRqX2Rlz4sN/Tj@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs pgsql-hackers |
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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jian He | 2022-04-06 05:01:55 | stxkind only explain two elements. left two unexplained. |
| Previous Message | Stephen Frost | 2022-04-05 17:10:38 | Re: Improve documentation for pg_upgrade, standbys and rsync |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-04-05 19:16:20 | Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.] |
| Previous Message | Imseih (AWS), Sami | 2022-04-05 18:45:09 | Re: Add index scan progress to pg_stat_progress_vacuum |