| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Pang <robertpang(at)google(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Back-patch of: avoid multiple hard links to same WAL file after a crash |
| Date: | 2025-03-10 06:21:04 |
| Message-ID: | Z86E0BhjiiZQURvL@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 10, 2025 at 02:25:28PM +0900, Michael Paquier wrote:
> I am attaching a full set of patches for v14 and v13 that can be used
> for these tests. WDYT?
And I forgot to mention that I've checked both v14 and v13, where I
have noticed the two patterns "invalid magic number 0000 in log
segment X, offset 0" and "unexpected pageaddr X in log segment Y" as
LOG and DEBUG entries.
These are gone once the patches are applied on both branches. Just
set max_wal_size and min_wal_size (128MB here) low enough with a
standby doing archive recovery, and bulk-load WAL on the primary to
accelerate the reproduction of the problem. It takes a couple of
minutes to have these show up with the unpatched branches.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2025-03-10 06:24:29 | Re: Log connection establishment timings |
| Previous Message | Shlok Kyal | 2025-03-10 06:16:09 | Re: Restrict copying of invalidated replication slots |