Re: SIGABRT on 7.4.5

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

In response to

Browse pgsql-hackers by date

  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 ...