| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Daniel Gustafsson <daniel(at)yesql(dot)se>, "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt" |
| Date: | 2023-10-12 23:15:56 |
| Message-ID: | ZSh-LDi1vD0yuFZV@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 12, 2023 at 10:41:39AM -0400, David Steele wrote:
> After some more thought, I think we could massage the "pg_control in
> backup_label" method into something that could be back patched, with more
> advanced features (e.g. error on backup_label and pg_control both present on
> initial cluster start) saved for HEAD.
I doubt that anything changed in this area would be in the
backpatchable zone, particularly as it would involve protocol changes
within the replication commands, so I'd recommend to focus on HEAD.
Backward-compatibility is not much of a conern as long as the backend
is involved. The real problem here would be on the frontend side and
how much effort we should try to put in maintaining the code of
pg_basebackup compatible with older backends.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2023-10-12 23:21:15 | Re: interval_ops shall stop using btequalimage (deduplication) |
| Previous Message | Alena Rybakina | 2023-10-12 23:14:13 | Re: A new strategy for pull-up correlated ANY_SUBLINK |