Re: Prepared statements fail after schema changes with surprising error - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Prepared statements fail after schema changes with surprising error
Date
Msg-id 20921.1358959244@sss.pgh.pa.us
Whole thread Raw
In response to Re: Prepared statements fail after schema changes with surprising error  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Prepared statements fail after schema changes with surprising error
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I agree with that, but I think Tom's concern is more with the cost of
> too-frequent re-planning.  The most obvious case in which DDL might be
> frequent enough to cause an issue here is if there is heavy use of
> temporary objects - sessions might be rapidly creating and dropping
> objects in their own schemas.  It would be unfortunate if that forced
> continual replanning of queries in other sessions.  I think there
> could be other cases where this is an issue as well, but the
> temp-object case is probably the one that's most likely to matter in
> practice.

Yeah, that is probably the major hazard IMO too.  The designs sketched
in this thread would be sufficient to ensure that DDL in one session's
temp schema wouldn't have to invalidate plans in other sessions --- but
is that good enough?

Your point that the locking code doesn't quite cope with newly-masked
objects makes me feel that we could get away with not solving the case
for plan caching either.  Or at least that we could put off the problem
till another day.  If we are willing to just change plancache's handling
of search_path, that's a small patch that I think is easily doable for
9.3.  If we insist on installing schema-level invalidation logic, it's
not happening before 9.4.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Next
From: Robert Haas
Date:
Subject: Re: CF3+4 (was Re: Parallel query execution)