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

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Actually it's a bufmgr issue (was Re: Another pg_listener issue)
Date: 2000-05-16 23:17:51
Message-ID: 000a01bfbf8c$f5278dc0$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]

[snip]

> 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?
>

Agreed.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Raul Chirea 2000-05-17 00:02:17 Re: Casting, again
Previous Message Tom Lane 2000-05-16 21:40:36 Re: type conversion discussion