Re: FSM, now without WAL-logging

Heikki Linnakangas <heikki.linnakangas@enterprisedb.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