Re: pg_rewind WAL segments deletion pitfall

Alvaro Herrera <alvherre@alvh.no-ip.org>

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Alexander Kukushkin <cyberdemn@gmail.com>
Cc: Sutou Kouhei <kou@clear-code.com>, smithpb2250@gmail.com, torikoshia@oss.nttdata.com, horikyota.ntt@gmail.com, michael@paquier.xyz, pgsql-hackers@postgresql.org, bungina@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2024-11-12T19:18:30Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

Hello

After reading the whole thread a couple of times to make sure I
understood the problem correctly, I think the approach in the v10 patch
is a reasonable one.  I agree that it's better for maintainability to
keep a separate hash table.  I made some cosmetic adjustments -- didn't
find any fault in the code.  I also verified that the test is hitting
the problematic case.

So here's v11, which I'll try to get out tomorrow.

I also assessed back-patching this.  There's some conflicts, but nothing
serious, back to 14.  Unfortunately, 13 lacks requisite infrastructure,
so I think it'll have to stay as it is.  (12 is dead.)

Can you please verify that my explanation in the commit message is
sound?

Thanks

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)

Commits

  1. Fix newly introduced 010_keep_recycled_wals.pl

  2. Avoid deleting critical WAL segments during pg_rewind