Re: brin index vacuum versus transaction snapshots

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: brin index vacuum versus transaction snapshots
Дата
Msg-id 20150731194524.GB2441@postgresql.org
обсуждение исходный текст
Ответ на Re: brin index vacuum versus transaction snapshots  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: brin index vacuum versus transaction snapshots  (Kevin Grittner <kgrittn@ymail.com>)
Re: brin index vacuum versus transaction snapshots  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
> I think the real solution to this problem is to avoid use of
> GetTransactionSnapshot(), and instead use GetLatestSnapshot().  As far
> as I can see, that should completely close the hole.  This requires
> patching IndexBuildHeapRangeScan() to allow for that.

Actually I think there's another problem: if a transaction starts and
inserts a tuple into the page range, then goes to sleep, and then
another session does the summarization of the page range, session 1 is
seen as "in progress" by session 2 (so the scan does not see the new
tuple), but the placeholder tuple was not modified either because it was
inserted later than the snapshot.  So the update is lost.

I think the only way to close this hole is to have summarize_range()
sleep until all open snapshots are gone after inserting the placeholder
tuple and before acquiring the snapshot, similarly to how CREATE INDEX
CONCURRENTLY does it.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: "Paragon Corporation"
Дата:
Сообщение: Use of PRId64 with PostgreSQL functions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );