core dump on select

Started by John Liuover 21 years ago4 messagesgeneral
Jump to latest
#1John Liu
johnl@stihealthcare.com

AIX pg version 7.4

Select * from document2 core dump. Did a few more experiments with select *
from document2 limit...

I limit to 500000 it works, 600000 it exits but says "calloc: There is not
enough memory available now."

I did a 573600 and it worked, then I did a 573700 and it core dumped. I
went back in and did the search again with 573700 and it then worked.

AIX:

core file size (blocks) 1048575

data seg size (kbytes) unlimited

file size (blocks) unlimited

max memory size (kbytes) 32768

open files 2000

pipe size (512 bytes) 64

stack size (kbytes) 2097151

cpu time (seconds) unlimited

max user processes 1000

virtual memory (kbytes) unlimited

Any thoughts on this? And how to generate the trace?

Thanks.

john

#2Andrew Sullivan
ajs@crankycanuck.ca
In reply to: John Liu (#1)
Re: core dump on select

On Fri, Sep 24, 2004 at 03:55:43PM -0500, John Liu wrote:

max memory size (kbytes) 32768

open files 2000

pipe size (512 bytes) 64

stack size (kbytes) 2097151

My guess is that one of these -- likely the first -- is biting you.
What isn't clear to me is whether you're getting core from the
postmaster or psql itself. I've seen the latter pretty frequently,
but there is a current segfault problem with AIX 5.1 at least.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

#3John Liu
johnl@stihealthcare.com
In reply to: Andrew Sullivan (#2)
Re: core dump on select

Core dump on select from psql on AIX 5.x

I have the following task at hand -
A huge table, one of the column data has duplicated entries. I want to find
those duplicated records in this column -
select count(*), col-x from table-x group by col-x having count(*) >1;

Of course, the above query will produce a core!! My question is: is there a
smart way in postgresql to solve this problem? Could I avoid this core dump
issue if I use pgplsql?

john
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Andrew Sullivan
Sent: Monday, September 27, 2004 8:38 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] core dump on select

On Fri, Sep 24, 2004 at 03:55:43PM -0500, John Liu wrote:

max memory size (kbytes) 32768

open files 2000

pipe size (512 bytes) 64

stack size (kbytes) 2097151

My guess is that one of these -- likely the first -- is biting you.
What isn't clear to me is whether you're getting core from the
postmaster or psql itself. I've seen the latter pretty frequently,
but there is a current segfault problem with AIX 5.1 at least.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

#4Martijn van Oosterhout
kleptog@svana.org
In reply to: John Liu (#3)
Re: core dump on select

On Mon, Sep 27, 2004 at 04:18:41PM -0500, John Liu wrote:

Core dump on select from psql on AIX 5.x

I have the following task at hand -
A huge table, one of the column data has duplicated entries. I want to find
those duplicated records in this column -
select count(*), col-x from table-x group by col-x having count(*) >1;

Of course, the above query will produce a core!! My question is: is there a
smart way in postgresql to solve this problem? Could I avoid this core dump
issue if I use pgplsql?

Do you really have that many duplicated rows? You're still not saying
if the core dump is in the client or in the server. If it's in the
client, do a SELECT INTO and then browse a limited portion from
there...

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Andrew Sullivan
Sent: Monday, September 27, 2004 8:38 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] core dump on select

On Fri, Sep 24, 2004 at 03:55:43PM -0500, John Liu wrote:

max memory size (kbytes) 32768

open files 2000

pipe size (512 bytes) 64

stack size (kbytes) 2097151

My guess is that one of these -- likely the first -- is biting you.
What isn't clear to me is whether you're getting core from the
postmaster or psql itself. I've seen the latter pretty frequently,
but there is a current segfault problem with AIX 5.1 at least.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Show quoted text

Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.