| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Emond Papegaaij <emond(dot)papegaaij(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_rewind after promote |
| Date: | 2024-03-28 22:01:52 |
| Message-ID: | e7b16ddea93a92575cb6d143b6ef602cab22432e.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 2024-03-28 at 17:17 +0100, Emond Papegaaij wrote:
> Op do 28 mrt 2024 om 16:21 schreef Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>:
> > On Thu, 2024-03-28 at 15:52 +0100, Emond Papegaaij wrote:
> > > pg_rewind: source and target cluster are on the same timeline pg_rewind: no rewind required
> > >
> > > If we ignore the response from pg_rewind, streaming will break on the node that reported
> > > no rewind was required. On the new primary, we do observe the database moving from timeline
> > > 21 to 22, but it seems this takes some time to materialize to be observable by pg_rewind.
> >
> > This must be the problem addressed by commit 009eeee746 [1].
> >
> > A temporary workaround could be to explicitly trigger a checkpoint right after
> > promotion.
>
> Would this be as simple as sending a CHECKPOINT to the new primary just after promoting?
> This would work fine for us until we've migrated to v16.
Yes, that would be the idea.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erik Wienhold | 2024-03-28 22:22:07 | Re: Grants and privileges issue |
| Previous Message | Ron Johnson | 2024-03-28 21:54:58 | Re: Cron not running |