"Tom Lane" <[EMAIL PROTECTED]> writes
> So it'll get an error ... this scenario doesn't strike me as any worse
> than any other problem occuring in post-commit cleanup. The locks left
> around by the not-cleaned-up transaction would probably be a bigger
> issue, for example.
Yes, the result is a
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> What if AtEOXact_Inval() fails (though the chance is slim)? Does that mean
> that smgrDoPendingDeletes() -> DropRelFileNodeBuffers can never get
> executed, which means we can never "dropped without write" the buffers
> belonging to the victim relation?
"Tom Lane" <[EMAIL PROTECTED]> writes
> It strikes me that the FlushRelationBuffers call is unnecessary and
> causes useless I/O, namely writing out pages into a file that's
> about to be deleted anyway. If we simply removed it then any buffers
> belonging to the victim relation would stay in mem
Simon Riggs <[EMAIL PROTECTED]> writes:
> ISTM that buffers belonging to the victim relation would not necessarily
> stay in memory.
Right. They'd be unpinned and therefore candidates for being written
out and recycled. So we *might* write them before they are dropped.
That's still better than *
