Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

From: "Vitaly Davydov" <v(dot)davydov(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Date: 2024-12-13 14:34:01
Message-ID: 135e8-675c4600-21-304d7f40@228322535
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 11/21/24 14:59, Tomas Vondra wrote:
>
> I don't have a great idea how to improve this. It seems wrong for
> ReplicationSlotsComputeRequiredLSN() to calculate the LSN using values
> from dirty slots, so maybe it should simply retry if any slot is dirty?
> Or retry on that one slot? But various places update the restart_lsn
> before marking the slot as dirty, so right now this won't work.

To ping the topic, I would like to propose a new version of my patch. All the check-world tests seems to pass ok.

The idea of the patch is pretty simple - keep flushed restart_lsn in memory and use this value to calculate required lsn in ReplicationSlotsComputeRequiredLSN().

One note - if restart_lsn_flushed is invalid, the restart_lsn value will be used. If we take invalid restart_lsn_flushed instead of valid restart_lsn the slot will be skipped. At the moment I have no other ideas how to deal with invalid restart_lsn_flushed.

With best regards,
Vitaly

Attachment Content-Type Size
0001-Keep-WAL-segments-by-slot-s-flushed-restart-LSN.patch text/x-patch 6.3 KB
0002-Fix-src-recovery-t-001_stream_rep.pl-after-changes-i.patch text/x-patch 999 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Önder Kalacı 2024-12-13 15:03:31 Re: Allow FDW extensions to support MERGE command via CustomScan
Previous Message Zaid Shabbir 2024-12-13 14:25:01 OLEDB provider for PostgreSQL