Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Goel, Dhruv
Тема Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY
Дата
Msg-id F0162FD7-39F7-4FE2-B94E-2D170B3F0DF8@amazon.com
обсуждение исходный текст
Ответ на Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY  ("Goel, Dhruv" <goeldhru@amazon.com>)
Список pgsql-hackers
> On Jun 9, 2019, at 5:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@anarazel.de> writes:
>> On June 9, 2019 8:36:37 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think you are mistaken that doing transactional updates in pg_index
>>> is OK.  If memory serves, we rely on xmin of the pg_index row for
>>> purposes such as detecting whether a concurrently-created index is safe
>>> to use yet.

I took a deeper look regarding this use case but was unable to find more evidence. As part of this patch, we
essentiallymake concurrently-created index safe to use only if transaction started after the xmin of Phase 3. Even
todayconcurrent indexes can not be used for transactions before this xmin because of the wait (which I am trying to get
ridof in this patch), is there any other denial of service you are talking about? Both the other states indislive,
indisreadycan be transactional updates as far as I understand. Is there anything more I am missing here? 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: tableam: abstracting relation sizing code
Следующее
От: Ashwin Agrawal
Дата:
Сообщение: Re: heapam_index_build_range_scan's anyvisible