Re: ERROR: cache lookup failed for type

On 08/16/2015 09:46 PM, Stuart wrote:
> On 08/17/2015 08:08 AM, Adrian Klaver wrote:
>> So this is what you did when you started with the Alpha 1 database,
>> correct?
>>
>> When you went to Alpha 2 you just installed the new program over the
>> existing Alpha 1, but left the data directory as is and then ran into
>> the error, correct?
>>
>> You then did a dump of the Alpha 1 or other(?) existing database and
>> then a restore into the Alpha 2(the reload above) at which point the
>> error went away, correct?
>
> Adrian, that is correct. More precisely, the steps taken were the
> following which I now see where I may have potentially introduced the error:
>
> upgrade from prostgres 9.4.4 to 9.5alpha1
>
> pg_dumpall > file.sql
> pg_ctl stop
> upgrade postgres 9.5alpha1
> rm -r /pgdir/*
> initdb -D /pgdir/
> pg_ctl start -D /pgdir/
> psql template1 -f file.sql
>
>
> upgrade from postgres 9.5alpha1 to 9.5alpha2
>
> upgrade postgres 9.5alpha1
> pg_ctl stop
> pg_ctl start -D /pgdir/
>
>
> Now I see that not stopping the database prior to the upgrade may have
> introduced the problem eventhough I don't understand the internals.  I
> did do another pg_ctl stop/start after upgrade just to see if that would
> fix but it didn't.

Yeah, I would say all bets are off when overwriting a running database.

How are you doing the upgrade, from a package or source?

I now the .deb packages allow for running multiple versions concurrently 
and I believe that yum can work that way also. If building from source 
you can do something like --prefix=/usr/local/pgsql94 in configure to 
separate  versions. Then you just have to change the port in 
postgresql.conf to have multiple versions on a machine. Somewhat less 
dangerous then deleting $DATA.


>
> I just did the following steps, and now no error:
>
> pg_dumpall > file.sql
> pg_ctl stop
> rm -r /pgdir/*
> initdb -D /pgdir/
> pg_ctl start -D /pgdir/
> psql template1 -f file.sql
>
> logged into db and recreated the function
>
> psql db
> create function ds_stats...
>
>
>
>
> Thanks,
>
> Stuart
>
>


-- 
Adrian Klaver
adrian.klaver@aklaver.com