Re: FSM, now without WAL-logging

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Hmm. The smgrtuncate WAL record is generated after the file is
> truncated, so there's still a small window there, where we can be left
> with a truncated main fork, but no smgrtruncate record for it, and thus
> the page of the FSM representing the truncated blocks doesn't get zeroed
> at replay.

Hmm. I seem to recall that that ordering was intentional, but I don't
recall why just now. The code doesn't say but maybe there's something
in the archives. It does seem a little odd since it's an apparent
violation of the wal-before-data rule.

If you wanted to be certain that the WAL record existed you'd have to
not only generate it first but fsync it, which would be a bit of a
performance hit. OTOH I'm not sure we care about smgrtruncate being
really quick...

regards, tom lane