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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: type conversion discussion
Следующее
От: Raul Chirea
Дата:
Сообщение: Re: Casting, again