| 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: | Whole Thread | Raw Message | 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
| 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 |