From: | Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Problem in restoring data |
Date: | 2003-11-09 22:59:15 |
Message-ID: | 3FAEC6C3.7010101@trade-india.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
>Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> writes:
>
>
>> I face the following problem in transferring data from
>>pgsql 7.3.4 to pgsql 7.4 RC1 . I am piping the output of
>>pg_dumpall from 7.3 to 7.4 running on different port.
>>The problem is there is a gist index on txtidx type on a
>>non-public schema and when search_path does not include
>>public the index cannot be created.
>>
>>
>
>There is a post-7.3.4 bug fix in the 7.3 branch for this mistake:
>
>2003-10-02 18:25 tgl
>
> * src/backend/utils/adt/ruleutils.c (REL7_3_STABLE): When dumping
> CREATE INDEX, must show opclass name if the opclass isn't in the
> schema search path. Otherwise pg_dump doesn't correctly dump
> scenarios where a custom opclass is created in 'public' and then
> used by indexes in other schemas.
>
>Since the bug is in the backend and not pg_dump, you can't escape it by
>using the 7.4 version of pg_dump against the 7.3 server.
>
Ok,I read somewhere its always better to use more recent pg_dump while
migrating.
> You could
>recompile the server using the 7.3-branch-head version of ruleutils.c,
>
Thanks for the explanation , Shall do that please tell me how to fetch
ruleutils.c
from 7.3-branch-head (do not know the cvs commands O:-) ) , thanks again.
regds
mallah.
>though.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sean | 2003-11-09 23:56:58 | Re: phpPGAdmin Indexes, what does this do? |
Previous Message | Joe Conway | 2003-11-09 22:38:13 | Re: possible replace() bug - postgres 7.3.1 |