On Sun, 2005-03-20 at 12:28 -0500, Tom Lane wrote:
> > Removing FlushRelationBuffers in those circumstances will save a scan of
> > shared_buffers, but will it save I/O? Perhaps not, but I care more about
> > the O(N) operation on shared_buffers than I do about the I/O.
>
> Realistically, wasted I
"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 *
On Sat, 2005-03-19 at 18:53 -0500, Tom Lane wrote:
> Currently, in places like heap_drop_with_catalog, we issue a
> FlushRelationBuffers() call followed by smgrscheduleunlink().
> The latter doesn't actually do anything right away, but schedules
> a file unlink to occur after transaction commit.
>
Currently, in places like heap_drop_with_catalog, we issue a
FlushRelationBuffers() call followed by smgrscheduleunlink().
The latter doesn't actually do anything right away, but schedules
a file unlink to occur after transaction commit.
It strikes me that the FlushRelationBuffers call is unnecess
