Re: slow queries over information schema.tables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: slow queries over information schema.tables
Date
Msg-id CA+TgmoZTAPeh8jrMaaZNNAdj9X+q=cdT-dEvg-DmuJHkXVv9KA@mail.gmail.com
Whole thread Raw
In response to Re: slow queries over information schema.tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: slow queries over information schema.tables
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Statement-level rollback
Next
From: Robert Haas
Date:
Subject: Re: proposal: plpgsql pragma statement