Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date
Msg-id CANtu0ojz0apXnVia0reTL28eL2=__ev8aLsiH=1XfD_Z3dnkTw@mail.gmail.com
Whole thread Raw
In response to Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
Hello, Mathias!

>  though I suspect the SP-GIST tests to have
> bugs, as an intermediate version of my 0003 patch didn't trigger the
> tests to fail

It all fails on master - could you please detail what is "intermediate" in that case? Also, I think it is a good idea to add the same type of test to btree.

>  * XXX: In the future we should probably reorder these operations so
>  * we can apply the checks in block order, rather than index order.

I think it is already done in your patch, no?

Should we when use that mechanics for btree as well? It seems to be straight forward and non-invasive. In such case, "Unchecked" goes away, and it is each AM responsibility to call the check while holding the pin.

Best regards,
Mikhail.

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: MergeJoin beats HashJoin in the case of multiple hash clauses
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Commitfest app release on Feb 17 with many improvements