From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Steele <david(at)pgmasters(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incremental backup from a streaming replication standby fails |
Date: | 2024-07-22 17:05:46 |
Message-ID: | 0ce1566ff0194c283a32afc58fcf73859b9b1f12.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2024-07-22 at 09:37 -0400, Robert Haas wrote:
> How about something like this:
>
> An incremental backup is only possible if replay would begin from a
> later checkpoint than for the previous backup upon which it depends.
> On the primary, this condition is always satisfied, because each
> backup triggers a new checkpoint. On a standby, replay begins from the
> most recent restartpoint. As a result, an incremental backup may fail
> on a standby if there has been very little activity since the previous
> backup. Attempting to take an incremental backup that is lagging
> behind the primary (or some other standby) using a prior backup taken
> at a later WAL position may fail for the same reason.
Before I write a v2, a small question for clarification:
I believe I remember that during my experiments, I ran CHECKPOINT
on the standby server between the first backup and the incremental
backup, and that was not enough to make it work. I had to run
a CHECKPOINT on the primary server.
Does CHECKPOINT on the standby not trigger a restartpoint, or do
I simply misremember?
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-07-22 17:06:11 | Re: Add new COPY option REJECT_LIMIT |
Previous Message | Ahmed Yarub Hani Al Nuaimi | 2024-07-22 16:59:56 | Re: Lock-free compaction. Why not? |