Skip site navigation (1) Skip section navigation (2)

Re: BUG #4688: Bug in cache.

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oleg <serovOv(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4688: Bug in cache.
Date: 2009-03-03 15:28:43
Message-ID: 49AD4CAB.40600@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Oleg wrote:
>>> CREATE CAST (tmp_table AS composite_ad_texts)
>>> WITHOUT FUNCTION AS ASSIGNMENT;
> 
>> "WITHOUT FUNCTION" can only be used when both types are binary 
>> compatible. You might think that two composite types with the same 
>> fields are, but they're not: we store the OID of the composite type in 
>> the records.
> 
> Although this qualifies as pilot error (superusers are expected to know
> what they're doing), should we attempt to prevent the case?

We can't detect binary-incompatibility in general, so I presume you 
meant just for the case of composite types. Hmm, I guess we could do it 
in that case.

>  It doesn't
> seem like a tremendously unlikely mistake to make, and AFAICS there is
> no easy way to recover your data once you've done it.

I believe the command has been like that for a long time, and this is 
the first time someone managed to shoot one's foot. It was made much 
worse by the ALTER TABLE and DROP TABLE. But yeah, it seems easy enough 
to check for the composite types case, so let's do that.

Oleg replied off-list asking how to recover the data. I suggested 
resetting the OID counter to the OID of the dropped table with 
pg_resetxlog, recreating it, and doing a pg_dump/restore.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-03-03 15:37:43
Subject: Re: BUG #4688: Bug in cache.
Previous:From: Tom LaneDate: 2009-03-03 15:10:02
Subject: Re: BUG #4688: Bug in cache.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group