Re: concurrent index builds unneeded lock?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: concurrent index builds unneeded lock?
Дата
Msg-id 19418.1247328134@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: concurrent index builds unneeded lock?  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> I wonder whether an earlier more general proposal could have some
> leverage here though: some way to indicate that the transaction has
> taken all the locks it plans to take already. This was originally
> proposed as a way for vacuum to know it can ignore the snapshots of a
> transaction since it isn't going to access the table being vacuumed.

Again, this doesn't work for any interesting cases.  You can't for
example assume that a user-defined datatype won't choose to look into
tables that hadn't been accessed as of the start of the index build.
(This isn't a hypothetical example --- I believe PostGIS does some
such things already, because it keeps spatial reference definitions
in a central catalog table.)
        regards, tom lane


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: *_collapse_limit, geqo_threshold
Следующее
От: Tom Lane
Дата:
Сообщение: Re: *_collapse_limit, geqo_threshold