From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SIGABRT on 7.4.5 |
Date: | 2004-09-30 19:03:24 |
Message-ID: | 24446.1096571004@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Conway <mail(at)joeconway(dot)com> writes:
> I have been trying to troubleshoot a PL/R related issue on-and-off for a
> few weeks now, but this morning ran into what appears to be a more
> general issue related to 7.4.5 on x86_64. A full backtrace is below, and
> in it you can see that PL/R is never reached (but PL/pgSQL is). What is
> really odd is that the abort appears to happen because
> CacheMemoryContext is invalid.
It could hardly not have been set up yet, so I'm betting that this
indicates a memory-stomp problem somewhere that happens to be hitting
part of the CacheMemoryContext structure.
> I do *not* see this same failure on a
> different machine with a 32 bit build
Not too surprising; could be related to struct sizes, padding, trying to
cram a 64-bit pointer into a 32-bit field, who knows what.
> Any ideas? I'll request permission to provide the full script to
> reproduce this to someone offlist if it will help.
The odds are that it couldn't be reproduced except on the same
architecture. I do have access to some x86_64 machines at Red Hat,
though, so I can take a look if you can send me a test case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Serguei A. Mokhov | 2004-09-30 19:49:00 | pg_upgrade project: high-level design proposal of in-place upgrade facility |
Previous Message | Tom Lane | 2004-09-30 18:56:48 | Re: CREATE INDEX speeds up query on 31 row table ... |