Re: concurrent index builds unneeded lock?

Поиск
Список
Период
Сортировка
От Theo Schlossnagle
Тема Re: concurrent index builds unneeded lock?
Дата
Msg-id 3DE8DA35-533C-4CF4-9C09-5B96E1D8C9A7@omniti.com
обсуждение исходный текст
Ответ на Re: concurrent index builds unneeded lock?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: concurrent index builds unneeded lock?  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: *_collapse_limit, geqo_threshold
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: bytea vs. pg_dump