Re: Visibility map, partial vacuums

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Visibility map, partial vacuums
Дата
Msg-id 49070C29.9090508@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Visibility map, partial vacuums  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Visibility map, partial vacuums  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Visibility map, partial vacuums  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs wrote:
> On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
>> One option would be to just ignore that problem for now, and not 
>> WAL-log.
> 
> Probably worth skipping for now, since it will cause patch conflicts if
> you do. Are there any other interactions with Hot Standby? 
> 
> But it seems like we can sneak in an extra flag on a HEAP2_CLEAN record
> to say "page is now all visible", without too much work.

Hmm. Even if a tuple is visible to everyone on the master, it's not 
necessarily yet visible to all the read-only transactions in the slave.

> Does the PD_ALL_VISIBLE flag need to be set at the same time as updating
> the VM? Surely heapgetpage() could do a ConditionalLockBuffer exclusive
> to set the block flag (unlogged), but just not update VM. Separating the
> two concepts should allow the visibility check speed gain to more
> generally available. 

Yes, that should be possible in theory. There's no version of 
ConditionalLockBuffer() for conditionally upgrading a shared lock to 
exclusive, but it should be possible in theory. I'm not sure if it would 
be safe to set the PD_ALL_VISIBLE_FLAG while holding just a shared lock, 
though. If it is, then we could do just that.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Window Functions: v07 APIs and buffering strateties
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Visibility map, partial vacuums