Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564
От | Andres Freund |
---|---|
Тема | Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564 |
Дата | |
Msg-id | 20230417180009.akas7axm6vn5lxma@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"), File: "xlog.c", Line: 1055, PID: 13564
|
Список | 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@anarazel.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
В списке pgsql-hackers по дате отправления: