Thread: 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 > -----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 dump > > > 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/ >
"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 > -----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