, NO WARRANTY, NO NOTHING, just for you information.
Regards.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 3:58 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues
&qu
crash on simple query, story continues
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> On failure, strxfrm() returns (size_t)-1.
Not according to the Single Unix Specification, Linux, or HP-UX;
I don't have any others to check. But anyway, that is not causing
your
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> On failure, strxfrm() returns (size_t)-1.
Not according to the Single Unix Specification, Linux, or HP-UX;
I don't have any others to check. But anyway, that is not causing
your problem, since palloc(0) would complain not dump core.
> I am on
m on SunOS 5.8,
BTW on Linux it works
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:45 AM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues
"Maksim Likharev
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> ! I would say very interesting aproach,
> ! why not just
> xfrmsize = strxfrm(xfrmstr, NULL, 0);
strxfrm doesn't work that way (and if it did, it would give back a
malloc'd not a palloc'd string).
mlen + 1);
}
pfree(val);
val = xfrmstr;
}
-Original Message-
From: Maksim Likharev
Sent: Tuesday, July 08, 2003 9:35 AM
To: 'Tom Lane'
Cc: [EMAIL PROTECTED]; '[EMAIL PROTECTED]'
Subject: RE: [GENERAL] PG crash on simple query, story continues
main (2, ffbefccc, ffbefcd8, 2e9d88, 0, 0) + 2e4
00032da8 _start (0, 0, 0, 0, 0, 0) + 5c
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 29, 2003 3:25 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> LOG: server process (pid 2004) was terminated by signal 11
> Is there any way to see what really happened?
I would like to see a stack backtrace (get a core dump, use gdb
on it. See the archives for descriptions of the standard procedure...)
Is there any way to see what really happened?
I mean more exhausted debug info.
It seems like other server running same PG 7.3 and more or less
identical hardware is not affected by that.
Info starts here:
--main table
CREATE TABLE prod.t_documents (
documentid int4 NOT NULL,
docid char(16)
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> I have consistent PG crash on some query,
> so I was able to isolate a simple query that crash postgres...
> SELECT p.docid FROM prod.t_documents AS p
> INNER JOIN t_tempdocs AS t
> ON p.docid = t.docid
> LEFT OUTER JOIN prod.t_
Hi,
I have consistent PG crash on some query,
so I was able to isolate a simple query that crash postgres...
SELECT p.docid FROM prod.t_documents AS p
INNER JOIN t_tempdocs AS t
ON p.docid = t.docid
LEFT OUTER JOIN prod.t_refs AS ct
ON ct.docid = p
11 matches
Mail list logo
