Re: slow queries over information schema.tables

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: slow queries over information schema.tables
Дата
Msg-id CA+TgmoZTAPeh8jrMaaZNNAdj9X+q=cdT-dEvg-DmuJHkXVv9KA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: slow queries over information schema.tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: slow queries over information schema.tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Dec 6, 2018 at 12:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > If we called it at the start of every query, couldn't we dispense with
> > the call in relation_openrv_extended()?
>
> No.  You need to do AIM *after* obtaining the lock, else you still
> have the race condition that you can execute a query on a table
> without being aware of recent DDL on it.

Huh? The call in relation_openrv_extended() happens before acquiring the lock.

> What we could possibly do to close the gap cited above is to have
> plancache.c's CheckCachedPlan force an AIM call if it notices that
> the plan it wants to re-use has a non-empty PlanInvalItems list.
> If it does not, then there is nothing that AIM would cause invalidation
> for anyway.  This still leaves us with a query-duration-sized race
> condition window for DDL on functions and domains, but not any larger
> than that.

That would be a nice place to get.  Not perfect, but better than now.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Statement-level rollback
Следующее
От: Robert Haas
Дата:
Сообщение: Re: proposal: plpgsql pragma statement