Re: FSM, now without WAL-logging

Zdenek Kotala wrote:
> I'm testing this version now and I got core dump in initdb phase:
>
> 08047558 pgstat_count_heap_insert+0x20(840b120, 842d738, 80, 8047580)
> 08047608 heap_insert+0x124(840b120, 842d738, 0, 1, 1, 842d710)
> 08047638 simple_heap_insert+0x23(840b120, 842d738, 8367f60, 80cc25a, b,
> 8302cac)
> 08047668 InsertOneTuple+0x93(4da, 80479ec, 8047b88, 80cb0b3, 0, 0)
> 08047b88 boot_yyparse+0x7f1(0, feff0e68, 0, 1, 83ab990, fefcba94)
> 08047bb8 AuxiliaryProcessMain+0x41d(3, 83aad04, fee88540, 816b63b,
> fef00e40, 8047bf4)
> 08047bfc main+0x3a9(4, 83aad00, 8047c30)
> 08047c10 _start+0x80(4, 8047d04, 8047d2c, 8047d33, 8047d37, 0)
>
> Let me know if you need more info. (I'm not using fresh CVS snapshot but
> two weeks old)

pgstat_count_heap_insert is an odd place to crash. I'd suggest updating
your CVS snapshot, and "make clean".

Attached is a new version, now with WAL-logging of the FSM truncation. I
decided to go with the separate WAL record for that, rather than
piggybacking on the smgrtruncate's WAL record. It seems much better from
a modularity point of view this way. I've also worked on the comments,
renamed many of the internal functions, in a more coherent scheme, and I
also started using the "struct FSMAddress" you suggested a while ago.

But I don't think I've changed anything that could explain that crash.
Let me know if it still doesn't work.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com