Postgres Pro
Downloads
Home   >   mailing lists

Thread: WIP patch for plan invalidation

WIP patch for plan invalidation

From
Tom Lane
Date:
This is what I've done so far on the plan-invalidation project.  This
creates a plan cache manager module and restructures things enough for
prepared statements to use it (both those generated at the SQL level
by PREPARE, and those coming from extended query protocol messages).
I haven't yet done anything about plans cached via SPI, and there are
some other open issues too, notably making sure that the search_path
during a replan is the same as it was the first time.

This patch includes getting rid of QueryContext as well as the
ProcessUtility API changes I suggested recently.  That makes it a bit
wide-ranging, so I'm inclined to apply it soon before dealing with
SPI and the other loose ends.

Comments?

            regards, tom lane
Attachment

Re: WIP patch for plan invalidation

From
Gregory Stark
Date:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Comments?

Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

Re: WIP patch for plan invalidation

From
Gregory Stark
Date:
"Gregory Stark" <stark@enterprisedb.com> writes:

> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> Comments?
>
> Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?

sigh, nevermind.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

Re: WIP patch for plan invalidation

From
Tom Lane
Date:
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> Comments?

> Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?

I moved those calls into ProcessUtility to avoid having to pass an extra
argument to those functions.  You could call this either way, but there
was already precedent for doing PreventTransactionChain in
ProcessUtility --- several existing commands did it that way.  In the
patch as it stands, ProcessUtility does it for every command in which
the call is unconditional, and we only pass isTopLevel to command
subroutines that have some condition or other affecting what to do.
You could make about an equally good case for pushing all those
PreventTransactionChain calls out to the subroutines, but it didn't
really seem any prettier to do it that way.

            regards, tom lane