Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue)

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
>>>> This means vacuum doesn't necessarily flush all dirty buffers of
>>>> the target table. Doesn't this break the assumption of pg_upgrade ?
>>
>> No, because it does still flush the buffer.

> Yes FlushRelationBuffers notices and flushes dirty buffers >=
> the specified block. But doesn't it notice dirty buffers < the
> specified block ? Or does vacuum flush all pages < the
> specified block while processing ?

Oh, I see what you mean: even after a VACUUM, it's possible for
there to be unwritten dirty buffers for a relation, containing
either changes entered by an aborted transaction, or updates of
on-row status values made by non-VACUUM transactions. Hmm.
It's barely possible that the second case could break pg_upgrade,
if something before VACUUM had updated the on-row status values
in a page and then VACUUM itself had no reason to dirty the page.
If those status values never get written then pg_upgrade fails.

Maybe it would be a good idea for VACUUM to force out all dirty
pages for the relation even when theu're only dirty because of
on-row status updates. Normally we wouldn't care about risking
losing those updates, but for pg_upgrade we would.

I was about to change FlushRelationBuffers anyway to get rid of
the bogus warning message. What I propose to do is give it two
behaviors:
(1) write out dirty buffers at or beyond the specified block,
but don't remove buffers from pool; or
(2) remove buffers at or beyond the specified block from pool,
after writing them out if dirty.

VACUUM should apply case (2) beginning at the proposed truncation point,
and then apply case (1) starting at block 0.

Sound good?

regards, tom lane