Re: brin index vacuum versus transaction snapshots

On Fri, Jul 31, 2015 at 3:45 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>> 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.

That's gonna be really slow, though, right? Even if you rework things
so that vacuum inserts all the placeholder tuples first, then waits,
then does all the summarization, that could easily turn a vacuum that
would have finished in a second into one that instead takes multiple
hours. During that time an AV worker is pinned down, and all sorts of
badness can ensue.

Maybe I'm misunderstanding, but this whole thing seems like a pretty
serious problem for BRIN. :-(

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company