From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: trying again to get incremental backup |
Date: | 2023-09-01 14:30:23 |
Message-ID: | CA+TgmoYt5jXH4U6cu1dm9Oe2FTn1aae6hBNhZzJJjyjbE_zYig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hey, thanks for the reply.
On Thu, Aug 31, 2023 at 6:50 PM David Steele <david(at)pgmasters(dot)net> wrote:
> pg_subtrans, at least, can be ignored since it is excluded from the
> backup and not required for recovery.
I agree...
> Welcome to the club!
Thanks for the welcome, but being a member feels *terrible*. :-)
> I do not. My conclusion back then was that validating a physical
> comparison would be nearly impossible without changes to Postgres to
> make the primary and standby match via replication. Which, by the way, I
> still think would be a great idea. In principle, at least. Replay is
> already a major bottleneck and anything that makes it slower will likely
> not be very popular.
Fair point. But maybe the bigger issue is the work involved. I don't
think zeroing the hole in all cases would likely be that expensive,
but finding everything that can cause the standby to diverge from the
primary and fixing all of it sounds like an unpleasant amount of
effort. Still, it's good to know that I'm not missing something
obvious.
> No objections to 0001/0002.
Cool.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2023-09-01 14:38:12 | Avoid a possible null pointer (src/backend/utils/adt/pg_locale.c) |
Previous Message | Jelte Fennema | 2023-09-01 14:04:58 | Re: Should we use MemSet or {0} for struct initialization? |