From: | Peter van Hardenberg <pvh(at)pvh(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prepared statements fail after schema changes with surprising error |
Date: | 2013-01-22 06:45:45 |
Message-ID: | CAAcg=kUewHdRkc37_wva5iW9E-MqZU4yoaF7vt04rRjFr3eAdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 * from z1;
PREPARE
regression=# insert into z1 values (1);
INSERT 0 1
regression=# execute sz1;
f1
----
1
(1 row)
# In another terminal window
$ pg_dump -F c regression > test.dump
$ pg_restore --clean --no-acl --no-owner -d regression test.dump
ERROR: cannot drop the currently open database
STATEMENT: DROP DATABASE regression;
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2185; 1262 16384 DATABASE
regression pvh
pg_restore: [archiver (db)] could not execute query: ERROR: cannot drop
the currently open database
Command was: DROP DATABASE regression;
WARNING: errors ignored on restore: 1
$
# back in the same backend
regression=# execute sz1;
ERROR: relation "z1" does not exist
regression=# select * from z1;
f1
----
1
(1 row)
regression=#
On Mon, Jan 21, 2013 at 5:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> writes:
> > On 22 January 2013 00:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 distinct namespaces with the same nspname)
> > between executions of the prepared query?
>
> What I'm suspicious of is that Peter is complaining about an old
> version, or that there's some other critical piece of information he
> left out. I don't plan to speculate about causes without a concrete
> test case.
>
> regards, tom lane
>
--
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
From | Date | Subject | |
---|---|---|---|
Next Message | Peter van Hardenberg | 2013-01-22 07:01:38 | Re: Prepared statements fail after schema changes with surprising error |
Previous Message | Craig Ringer | 2013-01-22 06:32:31 | Re: Patch for removng unused targets |