From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: brin index vacuum versus transaction snapshots |
Date: | 2015-07-31 19:45:24 |
Message-ID: | 20150731194524.GB2441@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-07-31 20:00:12 | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Previous Message | Paragon Corporation | 2015-07-31 19:43:07 | Use of PRId64 with PostgreSQL functions |