From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564 |
Date: | 2023-04-17 18:00:09 |
Message-ID: | 20230417180009.akas7axm6vn5lxma@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-04-17 13:50:30 -0400, Tom Lane wrote:
> I wrote:
> > Yeah, I just came to the same conclusion. One thing I don't understand
> > yet: log_newpage_range is old (it looks like this back to v12), and
> > that Assert is older, so why doesn't this reproduce further back?
> > Maybe the state where all the pages are new didn't happen before?
>
> Bingo: bisecting shows the failure started at
>
> commit 3d6a98457d8e21d85bed86cfd3e1d1df1b260721
> Author: Andres Freund <andres(at)anarazel(dot)de>
> Date: Wed Apr 5 08:19:39 2023 -0700
>
> Don't initialize page in {vm,fsm}_extend(), not needed
>
> So previously, log_newpage_range could only have failed in very
> unlikely circumstances, whereas now it's not hard to hit when
> committing a table creation. I wonder what other bugs may be
> lurking.
Oh, interesting. We haven't initialized the extra pages added by
RelationAddExtraBlocks() (in <= 15) for quite a while now, so I'm a bit
surprised it causes more issues for the VM / FSM. I guess it's that it's quite
common in real workloads to contend on the extension lock and add extra
blocks, but not in simple single-threaded tests?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-04-17 18:02:15 | Re: Move defaults toward ICU in 16? |
Previous Message | Alexander Lakhin | 2023-04-17 18:00:00 | Fix typos and inconsistencies for v16 |