Re: brin index vacuum versus transaction snapshots

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: brin index vacuum versus transaction snapshots
Date: 2015-08-04 18:28:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas wrote:
> On Fri, Jul 31, 2015 at 3:45 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:

> > 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.

Yeah, it is bad and I was concerned about that too. Thankfully I found
another way to solve it, which is to forgo usage of MVCC here and
instead use SnapshotAny. There's already a mode in
IndexBuildHeapRangeScan that uses SnapshotAny, but it needs some tweaks
to do what we need. I'm going to propose a patch along those lines

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

With this new approach it shouldn't be.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-08-04 19:00:43 Re: [sqlsmith] subplan variable reference / unassigned NestLoopParams (was: [sqlsmith] Failed assertion in joinrels.c)
Previous Message Tom Lane 2015-08-04 18:09:41 Re: upgrade failure from 9.5 to head