Re: concurrent index builds unneeded lock? - Mailing list pgsql-hackers

From Theo Schlossnagle
Subject Re: concurrent index builds unneeded lock?
Date
Msg-id 3DE8DA35-533C-4CF4-9C09-5B96E1D8C9A7@omniti.com
Whole thread Raw
In response to Re: concurrent index builds unneeded lock?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: concurrent index builds unneeded lock?  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers

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

> Theo Schlossnagle <jesus@omniti.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







pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: *_collapse_limit, geqo_threshold
Next
From: Peter Eisentraut
Date:
Subject: Re: bytea vs. pg_dump