On Thu, Jan 24, 2013 at 6:17 PM, Tom Lane wrote:
> I wrote:
> > Here's a draft patch for that. I've not looked yet to see if there's
> > any documentation that ought to be touched.
>
> And now with the documentation. If I don't hear any objections, I plan
> to commit this tomorrow.
>
>
No objec
Tom Lane writes:
> I wrote:
>> Here's a draft patch for that. I've not looked yet to see if there's
>> any documentation that ought to be touched.
>
> And now with the documentation. If I don't hear any objections, I plan
> to commit this tomorrow.
Certainly no objections from me: I had only a
I wrote:
> Here's a draft patch for that. I've not looked yet to see if there's
> any documentation that ought to be touched.
And now with the documentation. If I don't hear any objections, I plan
to commit this tomorrow.
regards, tom lane
diff --git a/doc/src/sgml/plpg
Robert Haas writes:
> On Wed, Jan 23, 2013 at 11:40 AM, Tom Lane wrote:
>> 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
>>
On Wed, Jan 23, 2013 at 11:40 AM, Tom Lane wrote:
> 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?
>
> Y
Robert Haas 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 dro
2013/1/23 Robert Haas :
> On Wed, Jan 23, 2013 at 8:10 AM, Dimitri Fontaine
> wrote:
>> Really, live DDL is not that frequent, and when you do that, you want
>> transparent replanning. I can't see any use case where it's important to
>> be able to run DDL in a live application yet continue to oper
On Wed, Jan 23, 2013 at 8:10 AM, Dimitri Fontaine
wrote:
> Really, live DDL is not that frequent, and when you do that, you want
> transparent replanning. I can't see any use case where it's important to
> be able to run DDL in a live application yet continue to operate with
> the old (and in case
On Tue, Jan 22, 2013 at 12:44 PM, Tom Lane wrote:
> After reflecting on this a bit, I think that the problem may come from
> drawing an unjustified analogy between views and prepared statements.
> The code is certainly trying to treat them as the same thing, but
> perhaps we shouldn't do that.
>
>
Tom Lane writes:
> I'm thinking that the main argument for trying to do this is so that we
> could say "plan caching is transparent", full stop, with no caveats or
> corner cases. But removing those caveats is going to cost a fair
> amount, and it looks like that cost will be wasted for most usag
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> However, it could still come annoyingly
>> close to "any DDL invalidates all cached plans", at least for apps that
>> keep most of their objects in one schema. Not entirely sure it's worth
>> the implementation hassle and extra sin
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Anyway, we're not talking about
> a back-patched fix I think, but something we'd change in a new major
> release.
Agreed.
> However, it could still come annoyingly
> close to "any DDL invalidates all cached plans", at least for apps that
> keep most of the
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Instead of
>> re-establishing the original search_path in a rather vain hope that the
>> same objects will be re-selected by parse analysis, we should consider
>> that the prepared query has a dependency on the active search path, a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Instead of
> re-establishing the original search_path in a rather vain hope that the
> same objects will be re-selected by parse analysis, we should consider
> that the prepared query has a dependency on the active search path, and
> thus force a replan if t
Dimitri Fontaine writes:
> Tom Lane writes:
>>> DROP SCHEMA public;
>>> CREATE SCHEMA public;
>> changes the OID of schema public, whereas the search_path that's cached
>> for the cached plan is cached in terms of OIDs. So while there is a
>> table named public.z1 at the end of the sequence, it'
Robert Haas writes:
> On Tue, Jan 22, 2013 at 2:17 AM, Tom Lane wrote:
>> I think what's happening is that this bit:
>>> DROP SCHEMA public;
>>> CREATE SCHEMA public;
>> changes the OID of schema public, whereas the search_path that's cached
>> for the cached plan is cached in terms of OIDs. So
Tom Lane writes:
>> DROP SCHEMA public;
>> CREATE SCHEMA public;
>
> changes the OID of schema public, whereas the search_path that's cached
> for the cached plan is cached in terms of OIDs. So while there is a
> table named public.z1 at the end of the sequence, it's not in any schema
> found in
On Tue, Jan 22, 2013 at 2:17 AM, Tom Lane wrote:
> Peter van Hardenberg writes:
>> Okay - I've narrowed it down to an interaction with schema recreation.
>> Here's a minimal test-case I created by paring back the restore from the
>> pg_restore output until I only had the essence remaining:
>
> Hm
Peter van Hardenberg writes:
> Okay - I've narrowed it down to an interaction with schema recreation.
> Here's a minimal test-case I created by paring back the restore from the
> pg_restore output until I only had the essence remaining:
Hm ... I'm too tired to trace through the code to prove this
Okay - I've narrowed it down to an interaction with schema recreation.
Here's a minimal test-case I created by paring back the restore from the
pg_restore output until I only had the essence remaining:
-- setup
drop table z1;
create table z1 (f1 int);
insert into z1 values (1);
prepare sz1 as sele
Hm - I'm still able to recreate the test the user's running using
pg_dump/pg_restore. I'm still working to see if I can minimize the
test-case, but this is against 9.2.2. Would you prefer I test against HEAD?
regression=# create table z1 (f1 int);
CREATE TABLE
regression=# prepare sz1 as select *
Peter Geoghegan writes:
> On 22 January 2013 00:00, Tom Lane wrote:
>> Works for me ...
> That's what I thought. But looking at RangeVarGetRelidExtended() and
> recomputeNamespacePath(), do you suppose that the problem could be
> that access privileges used by the app differed for a schema (or,
2013/1/21 Peter van Hardenberg :
> A user reported an interesting issue today. After restoring a dump created
> with --clean on a running application in his development environment his
> application started complaining of missing tables despite those tables very
> clearly existing.
>
> After a litt
On 22 January 2013 00:00, Tom Lane wrote:
> Works for me ...
That's what I thought. But looking at RangeVarGetRelidExtended() and
recomputeNamespacePath(), do you suppose that the problem could be
that access privileges used by the app differed for a schema (or, more
accurately, two physically di
Peter van Hardenberg writes:
> A user reported an interesting issue today. After restoring a dump created
> with --clean on a running application in his development environment his
> application started complaining of missing tables despite those tables very
> clearly existing.
> After a little t
A user reported an interesting issue today. After restoring a dump created
with --clean on a running application in his development environment his
application started complaining of missing tables despite those tables very
clearly existing.
After a little thinking, we determined that this was due
26 matches
Mail list logo
