RE: Actually it's a bufmgr issue (was Re: Another pg_listener issue)
От | Hiroshi Inoue |
---|---|
Тема | RE: Actually it's a bufmgr issue (was Re: Another pg_listener issue) |
Дата | |
Msg-id | 000a01bfbf8c$f5278dc0$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Actually it's a bufmgr issue (was Re: Another pg_listener issue)
|
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.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@tpf.co.jp
В списке pgsql-hackers по дате отправления: