Re: Incremental backup from a streaming replication standby fails - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Incremental backup from a streaming replication standby fails
Date
Msg-id CA+TgmoYT3VzgtK8P-7MMNWCP0PJVHFdm2Tw0cPi8e0f2+TmoFQ@mail.gmail.com
Whole thread Raw
In response to Re: Incremental backup from a streaming replication standby fails  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
On Mon, Jul 22, 2024 at 1:05 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> 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?

It's only possible for the standby to create a restartpoint at a
write-ahead log position where the master created a checkpoint. With
typical configuration, every or nearly every checkpoint on the primary
will trigger a restartpoint on the standby, but for example if you set
max_wal_size bigger and checkpoint_timeout longer on the standby than
on the primary, then you might end up with only some of those
checkpoints ending up becoming restartpoints and others not.

Looking at the code in CreateRestartPoint(), it looks like what
happens if you run CHECKPOINT is that it tries to turn the
most-recently replayed checkpoint into a restartpoint if that wasn't
done already; otherwise it just returns without doing anything. See
the comment that begins with "If the last checkpoint record we've
replayed is already our last".

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Next
From: Ahmed Yarub Hani Al Nuaimi
Date:
Subject: Re: Lock-free compaction. Why not?