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

> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Tom Lane

[snip]

> 
> regression=# vacuum foo;
> NOTICE:  FlushRelationBuffers(foo, 0): block 0 is dirty (private 
> 1, global 1)
> VACUUM
> 
> This is being caused by the buffer manager changes I recently made
> to avoid doing unnecessary writes at commit.  After the DELETE, foo's
> buffer is written to disk, but at that point its (single) tuple is
> marked with an uncommitted xmax transaction.  The SELECT verifies the
> tuple is dead and changes its on-row status to xmax-committed, but
> *that change is not forced to disk* (the rationale being that even if
> we crashed without writing the change, it could be done again later).
> Now VACUUM comes along, finds no live tuples, and decides to truncate
> the relation to zero blocks.  During the truncation,
> FlushRelationBuffers sees that the buffer it's flushing is still marked
> dirty, and hence emits the above notice.
>

This means vacuum doesn't necessarily flush all dirty buffers of
the target table. Doesn't this break the assumption of pg_upgrade ? 
> 
> Comments anyone?
>

Some changes around bufmgr seems to be needed.
1) Provide a function which could flush all dirty buffers   and vacuum calls the function for example.
or
2) SetBufferCommitInfoNeedsSave() sets SharedBuffer   Changed and BufferDirtiedByMe. 
and/or
3) Flush dirty buffers even in case of abort.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp