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

> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)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(at)tpf(dot)co(dot)jp