Tom,
Since we host customer data, I have to get OK from the company attorney before
I can give you a full "howto create". I've been unable to recreate it without
a full database dump. I'm waiting for a call back on that. I also can't
recreate it on IA32.
I tried to replicate the issue on a uniproc P4/32, but it worked fine there,
so it does seem to be something specific about the fact that it's either
X86/64 or that it's dual proc. The production server has 4GB of ECC RAM.
I can consistently create the problem by dumping and reloading the database to
a different PG database, and running it there, so AFAICT I'm not bugging
anybody when I run this query.
In the meantime, I found the "debuginfo" rpm, and installed it without a
hitch. Luckily, it seems to "take effect" without having to restart the PG
daemon. (which is busy serving 10-20 people at any given moment...)
Again, here's the output from gdb. This looks a bit more useful, I hope this
helps!
Program received signal SIGSEGV, Segmentation fault.
slot_deform_tuple (slot=0xa669c8, natts=36) at heaptuple.c:1262
1262 off = att_addlength(off, thisatt->attlen, tp + off);
(gdb) bt
#0 slot_deform_tuple (slot=0xa669c8, natts=36) at heaptuple.c:1262
#1 0x000000000043c8f5 in slot_getattr (slot=0xa669c8, attnum=36,
isnull=0x7fbfffde87 "")
at heaptuple.c:1367
#2 0x000000000047a50a in FormIndexDatum (indexInfo=0xa66b60, slot=0xa669c8,
estate=0xa61190, values=0x7fbfffdf10, isnull=0x7fbfffdef0 "") at
index.c:962
#3 0x00000000004ebee3 in ExecInsertIndexTuples (slot=0xa669c8,
tupleid=0xa6efc4,
estate=0xa61190, is_vacuum=0 '\0') at execUtils.c:925
#4 0x00000000004e5265 in ExecutorRun (queryDesc=Variable "queryDesc" is not
available.
) at execMain.c:1437
#5 0x0000000000564312 in ProcessQuery (parsetree=Variable "parsetree" is not
available.
) at pquery.c:174
#6 0x0000000000565287 in PortalRun (portal=0xa5ed70,
count=9223372036854775807,
dest=0xa596f8, altdest=0xa596f8, completionTag=0x7fbfffe380 "") at
pquery.c:1076
#7 0x0000000000560f8b in exec_simple_query (
query_string=0xa440e0 "INSERT INTO lcclasses (id, schoolyear, modified,
entrydate, creator, status, name, location, city, maxclasssize,
prerequisites, cost, costnote, coursecode, section, credits, whytake,
materialsnote, te"...) at postgres.c:1014
#8 0x0000000000562e0e in PostgresMain (argc=4, argv=0xa0cca0,
username=0xa0cc60 "cworksdev") at postgres.c:3168
#9 0x000000000053d316 in ServerLoop () at postmaster.c:2852
#10 0x000000000053ea59 in PostmasterMain (argc=5, argv=0x9ea510) at
postmaster.c:943
#11 0x00000000005033c3 in main (argc=5, argv=0x9ea510) at main.c:256
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
##################################################
Postgresql.conf
listen_addresses = '127.0.0.1'
port = 5432
max_connections = 96
shared_buffers=250000
temp_buffers = 10000
max_prepared_transactions = 0
work_mem = 1024 # min 64, size in KB
maintenance_work_mem = 16384 # min 1024, size in KB
max_stack_depth = 9240
redirect_stderr = on # Enable capturing of stderr into log
log_directory = 'pg_log' # Directory where log files are
written
log_truncate_on_rotation = on # If on, any existing log file of the
same
log_rotation_age = 1440 # Automatic rotation of logfiles will
log_rotation_size = 0 # Automatic rotation of logfiles will
autovacuum = on
autovacuum_naptime = 600
lc_messages = 'en_US.UTF-8' # locale for system error
message
lc_monetary = 'en_US.UTF-8' # locale for monetary
formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
add_missing_from = on
-Ben
On Wednesday 25 January 2006 11:18, you wrote:
> Benjamin Smith <lists@xxxxxxxxxxxxxxxxxx> writes:
> > OK, here's the output:
> > (gdb) continue
> > Continuing.
>
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x000000000043c82c in heap_modifytuple ()
> > (gdb)
>
> > // not very hopeful, I'd think //
>
> You forgot the "bt" part ... although I'm not sure we'd learn a whole
> lot more without debug symbols.
>
> > Can I get a RHES/CENTOS PG 8.1 RPM with the symbols enabled?
>
> Current Red Hat practice is to put the debug symbols into separate
> "debuginfo" RPMs. Hopefully you can find the debuginfo RPM wherever
> you got the postgres RPM from.
>
> regards, tom lane
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978
