Обсуждение: pg_type

I added a field to pg_type, updated all the bootstrap catalog entries, 
changed Natts_pg_type, and (I think) fixed the two places in pg_type.c 
that construct pg_type entries. However, initdb fails at the sysviews 
creation stage - the core dump shows it failing as shown below. Anyone 
have a quick idea what I might have missed / done wrong? At this stage 
the new field is not actually used anywhere, so it can't be a problem 
with that.

thanks

andrew

Program terminated with signal 11, Segmentation fault.
#0 0x0000000000444eac in heap_formtuple (tupleDescriptor=0xa59930, 
values=0x7fff81f7c800, nulls=0x7fff81f7c930 ' ' <repeats 24 times>, 
"nn�") at heaptuple.c:157
157 if (ATT_IS_PACKABLE(att[i]) &&
(gdb) bt
#0 0x0000000000444eac in heap_formtuple (tupleDescriptor=0xa59930, 
values=0x7fff81f7c800, nulls=0x7fff81f7c930 ' ' <repeats 24 times>, 
"nn�") at heaptuple.c:157
#1 0x00000000004b3cbb in TypeCreate (typeName=0x7fff81f7cbb0 "pg_roles", 
typeNamespace=11, relationOid=10958, relationKind=118 'v', 
internalSize=<value optimized out>, typeType=99 'c',
typDelim=44 ',', inputProcedure=2290, outputProcedure=2291, 
receiveProcedure=2402, sendProcedure=2403, typmodinProcedure=0, 
typmodoutProcedure=0, analyzeProcedure=0, elementType=0, baseType=0,
defaultTypeValue=0x0, defaultTypeBin=0x0, passedByValue=0 '\0', 
alignment=100 'd', storage=120 'x', typeMod=-1, typNDims=0, 
typeNotNull=0 '\0') at pg_type.c:332
#2 0x00000000004a2e83 in heap_create_with_catalog 
(relname=0x7fff81f7cbb0 "pg_roles", relnamespace=11, reltablespace=0, 
relid=10958, ownerid=10, tupdesc=0xb30098, relkind=118 'v',
shared_relation=0 '\0', oidislocal=0 '\0', oidinhcount=0, 
oncommit=ONCOMMIT_NOOP, reloptions=0, allow_system_table_mods=1 '\001') 
at heap.c:740
#3 0x0000000000507774 in DefineRelation (stmt=0xb2ee28, relkind=<value 
optimized out>) at tablecmds.c:435
#4 0x000000000051ee95 in DefineView (stmt=0xacc538, queryString=<value 
optimized out>) at view.c:209

Andrew Dunstan <andrew@dunslane.net> writes:
> I added a field to pg_type, updated all the bootstrap catalog entries, 
> changed Natts_pg_type, and (I think) fixed the two places in pg_type.c 
> that construct pg_type entries. However, initdb fails at the sysviews 
> creation stage - the core dump shows it failing as shown below. Anyone 
> have a quick idea what I might have missed / done wrong?

One thing I've been burnt by in the past is failing to update the
pg_class.h DATA statement to show the right number of columns.  Also,
you fixed both representations of the attribute list in pg_attribute.h,
right?
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> I added a field to pg_type, updated all the bootstrap catalog entries, 
>> changed Natts_pg_type, and (I think) fixed the two places in pg_type.c 
>> that construct pg_type entries. However, initdb fails at the sysviews 
>> creation stage - the core dump shows it failing as shown below. Anyone 
>> have a quick idea what I might have missed / done wrong?
>>     
>
> One thing I've been burnt by in the past is failing to update the
> pg_class.h DATA statement to show the right number of columns.  Also,
> you fixed both representations of the attribute list in pg_attribute.h,
> right?
>
>     
>   

Thanks. Yes, it was both pg_class and pg_attribute that I had missed. 
All better now. ;-)

Now to use the field ....

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> One thing I've been burnt by in the past is failing to update the
>> pg_class.h DATA statement to show the right number of columns.  Also,
>> you fixed both representations of the attribute list in pg_attribute.h,
>> right?

> Thanks. Yes, it was both pg_class and pg_attribute that I had missed. 
> All better now. ;-)

Yeah, adding a column to one of the core "bootstrap" tables is a real
PITA.  But I guess we don't do it often enough to justify having more
infrastructure for that.

> Now to use the field ....

If it hasn't occurred to you already: please add a test or two in
typ_sanity.sql to check that the column is sane, eg the type it points
to is a varlena type that points back to the element type.
        regards, tom lane

Tom Lane wrote:
> Yeah, adding a column to one of the core "bootstrap" tables is a real
> PITA.  But I guess we don't do it often enough to justify having more
> infrastructure for that.
>   

Maybe we should beef up the comments in those few stratgegic headers 
files a bit though.

>> Now to use the field ....
>>     
> If it hasn't occurred to you already: please add a test or two in
> typ_sanity.sql to check that the column is sane, eg the type it points
> to is a varlena type that points back to the element type.
>
>   

Yeah, I have the test below so far - will fix more when I have the name 
generation bit done.

cheers

andrew

-- Make sure typarray points to a varlena array type of our own base
SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype,      p2.typelem, p2.typlen
FROM   pg_type p1 left join pg_type p2 on (p1.typarray = p2.oid)
WHERE  p1.typarray <> 0 AND      (p2.oid IS NULL OR p2.typelem <> p1.oid OR p2.typlen <> -1);