Skip site navigation (1) Skip section navigation (2)

Re: seg fault crashed the postmaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gordon Shannon <gordo169(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: seg fault crashed the postmaster
Date: 2010-12-31 20:44:39
Message-ID: 5834.1293828279@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
Gordon Shannon <gordo169(at)gmail(dot)com> writes:
> Sorry, I left that out.  Yeah, I wondered that too, since these tables do
> not use toast.

Hm.  Well, given that the stack trace suggests we're trying to access a
tuple value that's not there (bogus pointer, or data overwritten since
the pointer was created), the "invalid memory alloc request size"
message is believable as another manifestation of the same problem.
The odds seem pretty good that the "corrupt compressed data" message
has the same origin at bottom, although the lack of any obvious data
to be compressed in this table is confusing.  Maybe you could get that
from trying to copy over a garbage value of that one varchar column,
though.

I tried to replicate the problem here without success, which suggests to
me that maybe it's plan-dependent.  Can you show what EXPLAIN gives you
for the troublesome query?

Another point here is that your logs suggest that the query blocked
behind the previous updater of the row for a very long time --- 90 sec
in one case, 30 sec in another.  Is that the typical runtime for one of
these updates?  If not, can you identify what the blocking query was?
If it's something different from another instance of the identical
update, it'd be useful to know what.

			regards, tom lane

In response to

Responses

pgsql-general by date

Next:From: Gordon ShannonDate: 2010-12-31 21:06:16
Subject: Re: seg fault crashed the postmaster
Previous:From: Gordon ShannonDate: 2010-12-31 20:18:29
Subject: Re: seg fault crashed the postmaster

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group