Re: SIREAD lock versus ACCESS EXCLUSIVE lock

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Дата
Msg-id 17163.1307470205@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SIREAD lock versus ACCESS EXCLUSIVE lock  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: SIREAD lock versus ACCESS EXCLUSIVE lock  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> I think I've caught up with the rest of the class on why this isn't
> sane in DropAllPredicateLocksFromTableImpl, but I wonder about
> CheckTableForSerializableConflictIn.  We *do* expect to be throwing
> errors in here, and we need some way to tell whether an index is
> associated with a particular heap relation.  Is the catalog cache
> the right way to check that here, or is something else more
> appropriate?

Just to answer the question (independently of Heikki's concern about
whether this is needed at all): it depends on the information you have.
If all you have is the index OID, then yeah a catcache lookup in
pg_index is probably the best thing.  If you have an open Relation for
the index, you could instead look into its cached copy of its pg_index
row.  If you have an open Relation for the table, I'd think that looking
for a match in RelationGetIndexList() would be the cheapest, since more
than likely that information is already cached.
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: reducing the overhead of frequent table locks - now, with WIP patch
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SIREAD lock versus ACCESS EXCLUSIVE lock