Re: brin index vacuum versus transaction snapshots

On 30 July 2015 at 22:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > Kevin Grittner wrote:
> >> If you run `make installcheck` against a cluster with
> >> default_transaction_isolation = 'repeatable read' you get one
> >> failure:
>
> > I am tempted to say that we should just disallow to run vacuum on a
> > table containing a brin index in a transaction-snapshot transaction.
>
> Huh? We don't allow vacuum inside a (user started) transaction now.
> What new restriction are you proposing?
>

Forgive me, but I believe there is a confusion here. Nobody is changing
VACUUM.

The code comment mentioned as "full of it" by Kevin appears to be accurate
and appropriate.

The code is called by VACUUM and brin_summarize_new_values(). It can't be
VACUUM, as you say and as the comment already says, so it must be the
function brin_summarize_new_values().

The test assumes that the default_transaction_isolation is read committed
and so the test fails at other levels. If anything, it is the test that is
at fault.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services