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 |
Message-ID: | 20150804182812.GT2441@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
shortly.
> 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 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 |