VACUUM ANALYZE

Hi,

What about not having any free space left on
your hard drive?
I just found out that a vacuum analyze will use
many hard disk space.
In my case in requires allmost 2.0 GB.
Does anybody know why ?

Keep in touch,

Andras.

----- Original Message -----
From: "Ben-Nes Michael" <miki@canaan.co.il>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, July 17, 2001 3:02 PM
Subject: [GENERAL] VACUUM ANALYZE

No lock :(

I tried it on 2 dbs , both very small and new.

----- Original Message -----
From: "Fabrice Scemama" <gesnet@scemama.org>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Wednesday, July 18, 2001 6:39 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

nope, all my db (2) are extremly small (new) and I have 500 mb free

----- Original Message -----
From: "Andras Balogh" <abalogh@grafx.ro>
To: "Ben-Nes Michael" <miki@canaan.co.il>; <pgsql-general@postgresql.org>
Sent: Tuesday, July 17, 2001 4:27 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

Hi,

What about not having any free space left on
your hard drive?
I just found out that a vacuum analyze will use
many hard disk space.
In my case in requires allmost 2.0 GB.
Does anybody know why ?

Keep in touch,

Andras.

----- Original Message -----
From: "Ben-Nes Michael" <miki@canaan.co.il>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, July 17, 2001 3:02 PM
Subject: [GENERAL] VACUUM ANALYZE

Hi All

VACUUM ANALYZE;

return me the next error:

pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Any ideas ?

--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------

"Ben-Nes Michael" <miki@canaan.co.il> writes:

VACUUM ANALYZE;

pqReadData() -- backend closed the channel unexpectedly.

Can't help you with so little information. What Postgres version?
What platform? What shows up in the postmaster's stderr log?
(If you aren't keeping one, now's a good time to start.) Is there
a core file produced by the failed backend, and if so what do you
get from a debugger stack trace?

regards, tom lane

What version are you using, and what does your postgres
log show? There's probably more information there.

----- Original Message -----
From: "Ben-Nes Michael" <miki@canaan.co.il>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, July 17, 2001 5:02 AM
Subject: [GENERAL] VACUUM ANALYZE

Hi All

VACUUM ANALYZE;

return me the next error:

pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Any ideas ?

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi

I use 7.1.2 compiled with locale set to the he_IL

Last day I re initdb the whole data dir and dumped the data back to the
server.
Then I tried VACUM ANALYZE which worked :)
but next day it stopped working returning the next lines in the log (link)

http://www.canaan.co.il/users/miki/pg_errors.txt

--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------

----- Original Message -----
From: "Stephan Szabo" <acroyear_07030@yahoo.com>
To: "Ben-Nes Michael" <miki@canaan.co.il>; <pgsql-general@postgresql.org>
Sent: Tuesday, July 17, 2001 8:25 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

You might suffer from a deadlock.

On Tue, 17 Jul 2001, Ben-Nes Michael wrote:

It looks like the backend (I'd assume this one) crashed
with a segmentation fault.
This should leave a core file (I believe in your db data
directory). Can you use a debugger to get a back trace
from the core file?

On Wed, 18 Jul 2001, Ben-Nes Michael wrote:

Hi

Im never used gdb so I hope I extracted all the Info needed, any why here it
is:

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `postgres: admin canada-centre.co.il_album [local]
VACUUM '.
Program terminated with signal 11, Segmentation fault.
#0 0x4014d8e0 in ?? ()

----- Original Message -----
From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Wednesday, July 18, 2001 9:17 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

It looks like the backend (I'd assume this one) crashed
with a segmentation fault.
This should leave a core file (I believe in your db data
directory). Can you use a debugger to get a back trace
from the core file?

On Wed, 18 Jul 2001, Ben-Nes Michael wrote:

Hi

I use 7.1.2 compiled with locale set to the he_IL

Last day I re initdb the whole data dir and dumped the data back to the
server.
Then I tried VACUM ANALYZE which worked :)
but next day it stopped working returning the next lines in the log

(link)

At 15:27 17.7.2001, Andras Balogh wrote the following message:

Hi,

What about not having any free space left on
your hard drive?
I just found out that a vacuum analyze will use
many hard disk space.

Can no space on device during vacuum analyze trash the database?

Tomaz

"Ben-Nes Michael" <miki@canaan.co.il> writes:

Core was generated by `postgres: admin canada-centre.co.il_album [local]
VACUUM '.
Program terminated with signal 11, Segmentation fault.
#0 0x4014d8e0 in ?? ()

That doesn't look real promising, but try issuing a "bt" (backtrace)
command to gdb, and see if you get any routine names rather than just
addresses ...

regards, tom lane

Gr8, here it is :)

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `postgres: admin canada-centre.co.il_album [local]
VACUUM '.
Program terminated with signal 11, Segmentation fault.
#0 0x4014d8e0 in ?? ()
(gdb)
(gdb)
(gdb)
(gdb) bt
#0 0x4014d8e0 in ?? ()
#1 0x8123a52 in ?? ()
#2 0x8123a9f in ?? ()
#3 0x8123caa in ?? ()
#4 0x8135f3a in ?? ()
#5 0x80ae162 in ?? ()
#6 0x80ade39 in ?? ()
#7 0x80aa4a6 in ?? ()
#8 0x80aa415 in ?? ()
#9 0x80fd36f in ?? ()
#10 0x80fb295 in ?? ()
#11 0x80fc2ee in ?? ()
#12 0x80e7410 in ?? ()
#13 0x80e700f in ?? ()
#14 0x80e6285 in ?? ()
#15 0x80e5cd0 in ?? ()
#16 0x80c7521 in ?? ()
#17 0x400eaa2c in ?? ()

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>;
<pgsql-general@postgresql.org>
Sent: Thursday, July 19, 2001 8:13 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

Hmm, unfortunate (was hoping that only the bottom of the trace
was only addresses). Can you turn on --enable-debug (from configure),
recompile, and see if it crashes then and what the trace is from that?
I think that'd be sufficient in general to get routine names (if I'm
wrong, I'm sure Tom will correct me...)

On Fri, 20 Jul 2001, Ben-Nes Michael wrote:

"Ben-Nes Michael" <miki@canaan.co.il> writes:

(gdb) bt
#0 0x4014d8e0 in ?? ()
#1 0x8123a52 in ?? ()
#2 0x8123a9f in ?? ()
#3 0x8123caa in ?? ()
[ etc ]

Sigh, that's no help at all :-(. Looks like you are using a postgres
executable that's been stripped of all symbolic information. Don't
suppose you want to compile from source to make a more debuggable copy?

Actually, maybe it's not quite no help at all. I'm going to guess from
the numeric values that the core dump is occurring in a system library
(since the top address is so far different from the rest). Since this
is a vacuum analyze, and since it's on a redhat machine, I'm going to
leap to a conclusion: maybe you are running into the known strcoll()
bug. Are you running glibc earlier than 2.2.3? If so, an update to
2.2.3 may fix it. See the thread at

http://fts.postgresql.org/db/mw/msg.html?mid=1021209

regards, tom lane

Nope im using 2.2.18 but ill recompile it to enable debug and return with
the error

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Friday, July 20, 2001 8:01 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

"Ben-Nes Michael" <miki@canaan.co.il> writes:

(gdb) bt
#0 0x4014d8e0 in ?? ()
#1 0x8123a52 in ?? ()
#2 0x8123a9f in ?? ()
#3 0x8123caa in ?? ()
[ etc ]

Sigh, that's no help at all :-(. Looks like you are using a postgres
executable that's been stripped of all symbolic information. Don't
suppose you want to compile from source to make a more debuggable copy?

Actually, maybe it's not quite no help at all. I'm going to guess from
the numeric values that the core dump is occurring in a system library
(since the top address is so far different from the rest). Since this
is a vacuum analyze, and since it's on a redhat machine, I'm going to
leap to a conclusion: maybe you are running into the known strcoll()
bug. Are you running glibc earlier than 2.2.3? If so, an update to
2.2.3 may fix it. See the thread at

http://fts.postgresql.org/db/mw/msg.html?mid=1021209

regards, tom lane

--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------

oops, mistake yes i am using older version.

glibc-2.1.94-3
glibc-devel-2.1.94-3

ill upgrade then ill compile with enable-debug

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Friday, July 20, 2001 8:01 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

"Ben-Nes Michael" <miki@canaan.co.il> writes:

(gdb) bt
#0 0x4014d8e0 in ?? ()
#1 0x8123a52 in ?? ()
#2 0x8123a9f in ?? ()
#3 0x8123caa in ?? ()
[ etc ]

Sigh, that's no help at all :-(. Looks like you are using a postgres
executable that's been stripped of all symbolic information. Don't
suppose you want to compile from source to make a more debuggable copy?

Actually, maybe it's not quite no help at all. I'm going to guess from
the numeric values that the core dump is occurring in a system library
(since the top address is so far different from the rest). Since this
is a vacuum analyze, and since it's on a redhat machine, I'm going to
leap to a conclusion: maybe you are running into the known strcoll()
bug. Are you running glibc earlier than 2.2.3? If so, an update to
2.2.3 may fix it. See the thread at

http://fts.postgresql.org/db/mw/msg.html?mid=1021209

regards, tom lane

--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------

"Ben-Nes Michael" <miki@canaan.co.il> writes:

bug. Are you running glibc earlier than 2.2.3? If so, an update to
2.2.3 may fix it. See the thread at

Nope im using 2.2.18 but ill recompile it to enable debug and return with
the error

I think you are confusing kernel version with glibc version. AFAIK
there is not a glibc 2.2.18 (not yet, anyway). The newest available
from redhat is 2.2.3-13 --- see
ftp://rawhide.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/

regards, tom lane

took time but here it is after recompile with enable-debug

I attached a tex file contain the log and gdb output

[root@www he_IL]# gdb --core ./base/18729/core
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `postgres: admin canada-centre.co.il_album [local]
VACUUM'.
Program terminated with signal 11, Segmentation fault.
#0 0x401225ea in ?? ()
(gdb) bt
#0 0x401225ea in ?? ()
#1 0x08123bf6 in ?? ()
#2 0x08123c43 in ?? ()
#3 0x08123e4e in ?? ()
#4 0x08135dee in ?? ()
#5 0x080ae0ea in ?? ()
#6 0x080addc1 in ?? ()
#7 0x080aa40e in ?? ()
#8 0x080aa37d in ?? ()
#9 0x080fd423 in ?? ()
#10 0x080fb349 in ?? ()
#11 0x080fc3a2 in ?? ()
#12 0x080e73fc in ?? ()
#13 0x080e6fef in ?? ()
#14 0x080e6259 in ?? ()
#15 0x080e5ca4 in ?? ()
#16 0x080c7491 in ?? ()
#17 0x400b9177 in ?? ()
(gdb)

----- Original Message -----
From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Friday, July 20, 2001 6:59 PM
Subject: Re: [GENERAL] VACUUM ANALYZE

Hmm, unfortunate (was hoping that only the bottom of the trace
was only addresses). Can you turn on --enable-debug (from configure),
recompile, and see if it crashes then and what the trace is from that?
I think that'd be sufficient in general to get routine names (if I'm
wrong, I'm sure Tom will correct me...)

On Fri, 20 Jul 2001, Ben-Nes Michael wrote:

Gr8, here it is :)

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you

are

welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for

details.

This GDB was configured as "i386-redhat-linux".
Core was generated by `postgres: admin canada-centre.co.il_album [local]
VACUUM '.
Program terminated with signal 11, Segmentation fault.
#0 0x4014d8e0 in ?? ()
(gdb)
(gdb)
(gdb)
(gdb) bt
#0 0x4014d8e0 in ?? ()
#1 0x8123a52 in ?? ()
#2 0x8123a9f in ?? ()
#3 0x8123caa in ?? ()
#4 0x8135f3a in ?? ()
#5 0x80ae162 in ?? ()
#6 0x80ade39 in ?? ()
#7 0x80aa4a6 in ?? ()
#8 0x80aa415 in ?? ()
#9 0x80fd36f in ?? ()
#10 0x80fb295 in ?? ()
#11 0x80fc2ee in ?? ()
#12 0x80e7410 in ?? ()
#13 0x80e700f in ?? ()
#14 0x80e6285 in ?? ()
#15 0x80e5cd0 in ?? ()
#16 0x80c7521 in ?? ()
#17 0x400eaa2c in ?? ()

--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------

"Ben-Nes Michael" <miki@canaan.co.il> writes:

[root@www he_IL]# gdb --core ./base/18729/core

Try mentioning the postgres executable too:

gdb /path/to/postgres /path/to/core

Until you can get us a backtrace that shows some names, not numbers,
there's not a lot we can do.

FWIW, I still think you need to update your glibc, per
the thread at
http://fts.postgresql.org/db/mw/msg.html?mid=1021209

regards, tom lane