Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Dec 11, 2018 at 3:06 PM Tom Lane <tgl@sss.pgh.pa.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