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
-
Fix newly introduced 010_keep_recycled_wals.pl
- 2fb3919356fb 17.3 landed
- 50010c6f6c4d 16.7 landed
- 93d8d4fe1255 15.11 landed
- 1c5fe56bc259 14.16 landed
- b5be29ecafe1 18.0 landed
-
Avoid deleting critical WAL segments during pg_rewind
- ea1649c352f6 16.6 landed
- e28cf2fbc222 15.10 landed
- cb844d66b587 17.2 landed
- ba25358413e4 14.15 landed
- 90bcc7c2db1d 18.0 landed