Re: data corruption hazard in reorderbuffer.c

Hi,

I think it's mostly futile to list all the possible issues this might
have caused - if you skip arbitrary decoded changes, that can trigger
pretty much any bug in reorder buffer. But those bugs can be triggered
by various other issues, of course.

It's hard to say what was the cause, but the "logic" bugs are probably
permanent, while the issues triggered by I/O probably disappear after a
restart?

That being said, I agree this seems like an issue and we should not
ignore I/O errors. I'd bet other places using transient files (like
sorting or hashagg spilling to disk) has the same issue, although in
that case the impact is likely limited to a single query.

I wonder if sync before the close is an appropriate solution, though. It
seems rather expensive, and those files are meant to be "temporary"
(i.e. we don't keep them over restart). So maybe we could ensure the
consistency is a cheaper way - perhaps tracking some sort of checksum
for each file, or something like that?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company