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);