Re: Fixed length data types issue

From: Mark Dilger <pgsql(at)markdilger(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Fixed length data types issue
Date: 2006-09-14 01:23:11
Message-ID: 4508AEFF.7040304@markdilger.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Mark Dilger <pgsql(at)markdilger(dot)com> writes:
>> int1 works perfectly, as far as I can tell. int3 works great in memory,
>> but can't be stored to a table. The problem seems to be that
>> store_att_byval allows data of size 1 byte but not size 3 bytes, forcing
>> me to pass int3 by reference. But when I pass either of these types by
>> reference the backend exits when trying to store to a table.
>
> Please provide a stack trace --- AFAIK there shouldn't be any reason why
> a pass-by-ref 3-byte type wouldn't work. I'm wondering though what
> alignment you expect it to have. You'd need some pretty ugly code to
> pick up an unaligned 3-byte integer portably ... but if you align it,
> the space savings probably goes out the window.
>
> regards, tom lane

Program received signal SIGSEGV, Segmentation fault.
0xb7e01d45 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0xb7e01d45 in memcpy () from /lib/libc.so.6
#1 0x08077ece in heap_fill_tuple (tupleDesc=0x83c2ef7,
values=0x83c2e84, isnull=0x83c2e98 "", data=0x83c2ef4 "",
infomask=0x83c2ef0, bit=0x0)
at heaptuple.c:181
#2 0x08078b0d in heap_form_tuple (tupleDescriptor=0x83c2d78,
values=0x83c2e84, isnull=0x83c2e98 "") at heaptuple.c:749
#3 0x0815d2d9 in ExecCopySlotTuple (slot=0x83c26f4) at execTuples.c:558
#4 0x0815d393 in ExecMaterializeSlot (slot=0x83c26f4) at execTuples.c:639
#5 0x081560ca in ExecutorRun (queryDesc=0x83c2834,
direction=ForwardScanDirection, count=0) at execMain.c:1401
#6 0x081e78e4 in ProcessQuery (parsetree=0x83c2240, plan=0x83b837c,
params=0x3, dest=0x83b8290, completionTag=0xbfedffa0 "") at pquery.c:174
#7 0x081e89f9 in PortalRun (portal=0x83c0064, count=2147483647,
dest=0x83b8290, altdest=0x83b8290, completionTag=0xbfedffa0 "") at
pquery.c:1076
#8 0x081e4060 in exec_simple_query (query_string=0x83b7bbc "insert into
test (a) values (3::int3);") at postgres.c:1004
#9 0x081e6074 in PostgresMain (argc=4, argv=0x836fab4,
username=0x836fa8c "mark") at postgres.c:3219
#10 0x081b89b3 in ServerLoop () at postmaster.c:2854
#11 0x081ba21b in PostmasterMain (argc=1, argv=0x836d9f8) at
postmaster.c:941
#12 0x081764a8 in main (argc=1, argv=0x836d9f8) at main.c:265

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-14 01:45:35 Re: CSStorm occurred again by postgreSQL8.2
Previous Message Tom Lane 2006-09-14 00:55:12 Re: Optimizer improvements: to do or not to do?