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 |
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 |