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

A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD
Date: 2008-11-05 19:55:55
Message-ID: 4911FA4B.1000201@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
This patch:

> commit 35ad25ad66fa3999bbc0bb59ca13cef3d750fb07
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Date:   Sat Jul 26 19:15:35 2008 +0000
> 
>     As noted by Andrew Gierth, there's really no need any more to force a junk
>     filter to be used when INSERT or SELECT INTO has a plan that returns raw
>     disk tuples.  The virtual-tuple-slot optimizations that were put in place
>     awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that
>     already copies the tuple if it's raw (and does so more efficiently than
>     a junk filter, too).  So get rid of that logic.  This in turn means that
>     we can throw away ExecMayReturnRawTuples, which wasn't used for any other
>     purpose, and was always a kluge anyway.
>     
>     In passing, move a couple of SELECT-INTO-specific fields out of EState
>     and into the private state of the SELECT INTO DestReceiver, as was foreseen
>     in an old comment there.  Also make intorel_receive use ExecMaterializeSlot
>     not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save
>     a tuple copy step in some cases.
> 

made this test case crash:

CREATE TABLE xtable (padding char(2000)) WITH OIDS;
INSERT INTO xtable  VALUES('1');
ALTER TABLE xtable SET WITHOUT OIDS;
INSERT INTO xtable (SELECT * FROM xtable);

with assertion failure:

TRAP: FailedAssertion("!(!(tup->t_data->t_infomask & 0x0008))", File: 
"heapam.c", Line: 1782)

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

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-11-05 20:31:29
Subject: Re: A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD
Previous:From: Zdenek KotalaDate: 2008-11-05 19:55:25
Subject: Re: [WIP] In-place upgrade

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