| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 17:50:30 |
| Message-ID: | 2454846.1681753830@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I'll patch it back to v12 anyway, since that function is
clearly wrong in isolation.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-04-17 17:54:41 | Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564 |
| Previous Message | Corey Huinker | 2023-04-17 17:01:37 | Re: Note new NULLS NOT DISTINCT on unique index tutorial page |