Re: concurrent index builds unneeded lock?

On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:

> Theo Schlossnagle <jesus(at)omniti(dot)com> writes:
>> I would think it would be txns that would be reading that table, but
>> I'm thinking it is a bit to aggressive. Am I reading the code wrong
>> there? I'm thinking it should be more selective about vxids it
>> chooses to block on. I'd expect it to block on vxids touching the
>> same table only.
>
> There is no way to know whether a currently active vxid will try to
> look
> at the other table later. We can not just ignore this case...
>
> regards, tom lane

Can't you know "that" if the other active query in question is a
concurrent index build?

Concurrent index builds by their current implementation cannot exist
within another transaction, so you know everythere there is to know
about that transaction by looking at it (no risk of prior or future
work).

While very much unlike a vacuum (a special exclusion in concurrent
index builds), they still seem to constitute a "special case" for
exclusion.

Happy to be wrong here, I really haven't completely digested the code.

--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
p: +1.443.325.1357 x201 f: +1.410.872.4911