Re: Hot Standby dev build (v8)

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Hot Standby dev build (v8)
Дата
Msg-id 497428B0.2000607@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Hot Standby dev build (v8)  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Hot Standby dev build (v8)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs wrote:
> On Fri, 2009-01-16 at 22:09 +0200, Heikki Linnakangas wrote:
> 
>>>> RecentGlobalXmin is just a hint, it lags behind the real oldest xmin 
>>>> that GetOldestXmin() would return. If another backend has a more recent 
>>>> RecentGlobalXmin value, and has killed more recent tuples on the page, 
>>>> the latestRemovedXid written here is too old.
>>> What do you think we should do instead?
>> Dunno. Maybe call GetOldestXmin().
> 
> We are discussing btree deletes, not btree vacuums. 

Pardon my ignorance, but what's the difference?

> If we are doing
> btree delete then we have an unreleased snapshot therefore we also have
> a non-zero xmin. How can another backend have a later RecentGlobalXmin
> or result from GetOldestXmin() than we do?

Sure it can, for example:

1. Transaction 1 begins in backend A
2. Transaction 2 begins in backend B, xmin = 1
3. Transaction 1 ends
4. Transaction 3 begins in backend C, xmin = 2
5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1
6. Transaction 2 ends.
7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2, 
RecentGlobalXmin = 2
8. Transaction 4 kills tuple, using its RecentGlobalxmin of 1
9. Transaciont 3 splits the page, emits a delete xlog record, setting 
latestRemovedXid to its RecentGlobalXmin of 2

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


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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: [PATCHES] GIN improvements
Следующее
От: Bernd Helmle
Дата:
Сообщение: Re: WIP: Automatic view update rules