core dump
I've two questions, they may or may not be related -
1. I copied the entire data directory [including
postgresql.conf, base, ...] from postgreSQL 7.3.2 (AIX4.3)
to the installation postgreSQL 7.3.4 (AIX5.1), the same filesystem
setup. I didn't do an dump/reload process
since the copy process is faster.
Is it OK to take this shortcut in postgreSQL? any side-effects?
2. The copied database with 7.3.4 pgsql and 7.3.2 data dir seems
running OK. But when I run the following query it causes core dump -
psql -d emrxdbs -At -F '|' -c "select cdi, doctypeid,
getdatatype(doctypeid) from document;"
out
but the above query works on the older AIX4.3 postgreSQL7.3.2, and
if I run the following query it works on new AIX5.1 -
psql -d emrxdbs -At -F '|' -c "select cdi, doctypeid,
getdatatype(doctypeid) from document limit 10;" >out
strings core indicates some memory issues,
but the new AIX5.1 has far more memory than the old AIX4.3 -
...
SELECT relname FROM pg_catalog.pg_listener WHERE substr(relname,1,%d)='%s'
UNION SELECT '*'::name
pgSELECT relname FROM pg_catalog.pg_class WHERE relkind='r' and
substr(relname,1,%d)='%s' and pg_catalog.pg_t
able_is_visible(oid) UNION SELECT 'FULL'::name UNION SELECT 'ANALYZE'::name
format
Tborder
Wexpanded
VERnull
fieldsep
tuples_only
title
ATtableattr
LLpager
EXrecordsep
IBMout of memory
ISELECT c1.relname FROM pg_catalog.pg_class c1, pg_catalog.pg_class c2,
pg_catalog.pg_index i WHERE c1.oid=i.
indrelid and i.indexrelid=c2.oid and c2.relname='%s' and
pg_catalog.pg_table_is_visible(c2.oid)
BINARY
...
IBM\out
IBM\s
I\write
I%s LIMIT %d;
out of memory
ION_ERROR_STOP
IBIGNOREEOF
IBQUIET
IB\q
IUse "\q" to leave %s.
IECHO
IBMall
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_
%.*s%s%s
IBM
IBMSINGLELINE
@(#)61
1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos510 7/11/00
12:04:14
set client_encoding to '%s'
xrealloc
xmalloc
%s: out of virtual memory
...
Any thoughts?
thanks.
johnl
On Wed, 19 Nov 2003 11:55:46 -0600
"John Liu" <johnl@emrx.com> wrote:
I've two questions, they may or may not be related -
1. I copied the entire data directory [including
postgresql.conf, base, ...] from postgreSQL 7.3.2 (AIX4.3)
to the installation postgreSQL 7.3.4 (AIX5.1), the same filesystem
setup. I didn't do an dump/reload process
since the copy process is faster.Is it OK to take this shortcut in postgreSQL? any side-effects?
If you did this while PG was running you have a big pile of meaningless
data. The only two ways to do this are to shut down PG and copy or use
an LVM and take a snapshot.
--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
PG was shutdown on both AIXs,
otherwise it may not be able
to start up after the copy.
thanks.
johnl
Show quoted text
-----Original Message-----
From: Jeff [mailto:threshar@torgo.978.org]
Sent: Wednesday, November 19, 2003 12:03 PM
To: John Liu
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] core dumpOn Wed, 19 Nov 2003 11:55:46 -0600
"John Liu" <johnl@emrx.com> wrote:I've two questions, they may or may not be related -
1. I copied the entire data directory [including
postgresql.conf, base, ...] from postgreSQL 7.3.2 (AIX4.3)
to the installation postgreSQL 7.3.4 (AIX5.1), the same filesystem
setup. I didn't do an dump/reload process
since the copy process is faster.Is it OK to take this shortcut in postgreSQL? any side-effects?
If you did this while PG was running you have a big pile of meaningless
data. The only two ways to do this are to shut down PG and copy or use
an LVM and take a snapshot.--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
"John Liu" <johnl@emrx.com> writes:
1. I copied the entire data directory [including
postgresql.conf, base, ...] from postgreSQL 7.3.2 (AIX4.3)
to the installation postgreSQL 7.3.4 (AIX5.1), the same filesystem
setup. I didn't do an dump/reload process
since the copy process is faster.
Is it OK to take this shortcut in postgreSQL? any side-effects?
Given that you are now seeing problems on the new installation, it seems
it didn't work too well :-(
I'm not sure why though. 7.3.2->7.3.4 should not have any file-level
incompatibilities, assuming you built both with the same configure
options (might be worth double-checking that). The OS version jump
might possibly be the culprit --- is it possible they changed the
compiler's struct packing rules between 4.3 and 5.1? Oh, and I'm
assuming these systems are the same underlying hardware architecture ...
regards, tom lane
the query worked before on the old installations,
now also core dump in the old installations [I can't think of
any settings' changes, the olnly change is the volume of the data
increased],
which might be indicated the core dump issue
is caused by something else.
Here's the logs whenever this core dump happens -
2003-11-24 14:22:25 LOG: pq_flush: send() failed: Broken pipe
is it socket related? how and why?
Again, the same query + "limit 20000" works.
thanks.
johnl
Show quoted text
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, November 21, 2003 12:42 PM
To: John Liu
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] core dump"John Liu" <johnl@emrx.com> writes:
1. I copied the entire data directory [including
postgresql.conf, base, ...] from postgreSQL 7.3.2 (AIX4.3)
to the installation postgreSQL 7.3.4 (AIX5.1), the same filesystem
setup. I didn't do an dump/reload process
since the copy process is faster.Is it OK to take this shortcut in postgreSQL? any side-effects?
Given that you are now seeing problems on the new installation, it seems
it didn't work too well :-(I'm not sure why though. 7.3.2->7.3.4 should not have any file-level
incompatibilities, assuming you built both with the same configure
options (might be worth double-checking that). The OS version jump
might possibly be the culprit --- is it possible they changed the
compiler's struct packing rules between 4.3 and 5.1? Oh, and I'm
assuming these systems are the same underlying hardware architecture ...regards, tom lane
"John Liu" <johnl@emrx.com> writes:
the query worked before on the old installations,
now also core dump in the old installations [I can't think of
any settings' changes, the olnly change is the volume of the data
increased],
Hmm ... are you approaching 2Gb of data in the dump? If so maybe you
forgot to enable large-file support when building pg_dump. A short-term
workaround might be to enable compression of the dump, but in the long
run you'd best rebuild.
regards, tom lane
