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
