Re: Sketch of a fix for that truncation data corruption issue

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Dec 11, 2018 at 3:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Anyway, if your assumption is that WAL replay must yield bit-for-bit
>> the same state of the not-truncated pages that the master would have,
>> then I doubt we can make this work. In that case we're back to the
>> type of solution you rejected eight years ago, where we have to write
>> out pages before truncating them away.

> How much have you considered the possibility that my rejection of that
> approach was a stupid and wrong-headed idea? I'm not sure I still
> believe that not writing those buffers would have a meaningful
> performance cost.

Well, if *you're* willing to entertain that possiblity, I'm on board.
That would certainly lead to a much simpler, and probably back-patchable,
fix.

> Truncating relations isn't that common of an
> operation, and also, we could mitigate the impacts by having the scan
> that identifies the truncation point also write any dirty buffers
> after that point. We'd have to recheck after upgrading our relation
> lock, but odds are good that in the normal case we wouldn't add much
> to the time when we hold the stronger lock.

Hm, not quite following this? We have to lock out writers before we
try to identify the truncation point.

regards, tom lane