RE: Actually it's a bufmgr issue (was Re: Another pg_listener issue) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: Actually it's a bufmgr issue (was Re: Another pg_listener issue)
Date
Msg-id NDBBIJLOILGIKBGDINDFAEBMCFAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> 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 ?
>
> 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 ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



pgsql-hackers by date:

Previous
From: Brian E Gallew
Date:
Subject: Re: Berkeley DB license
Next
From: Tom Lane
Date:
Subject: Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue)