VACUUM ANALYZE failed on linux

From: Oleg Broytmann <phd(at)sun(dot)med(dot)ru>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: VACUUM ANALYZE failed on linux
Date: 1999-01-29 15:54:15
Message-ID: Pine.SOL2.3.96.SK.990129184111.2434A-100000@sun.med.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello!

I have a production server with Postgres 6.4.2. Every night crom runs
maintainance script, that contayned VACUUM ANALYZE (I use psql).
Few days ago the scrip failed with usual "... backend closed
connection". I changed it to just VACUUM (this worked) and started
investigation. Please note, the system is RedHat 5.1 on Pentium.

I dumped the datbase and reloaded it, then ran VACUUM ANALYZE. It failed
(I removed pg_vlock, of course).
I loaded the dump into 6.4.2 on my debugging server - Ultra-1, Solaris
2.5.1 and ran VACUUM ANALYZE. It worked.
I loaded the dump into 6.4.2 on my debugging Pentium with Debian 2.0 and
ran VACUUM ANALYZE. It failed.

Seems 6.4.2 has problems on linux. Dump file is small (30K in bzip2) - I
can send it if someone want to try to reproduce it.

BTW, while reloading, I noticed postgres eats virtual memory like a
hungry beast. My RedHat booted on loading (but after reboot db loaded ok). I
have to free much memory on Solaris to load the dump. Does "COPY FROM stdin"
really require so much memory? And how I will feel when my database will
grow even bigger? Sooner or later I couldn't load my own dump. Will I need
to split the dump into chunks?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2(at)earthling(dot)net
Programmers don't die, they just GOSUB without RETURN.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Patrick Verdon 1999-01-29 16:05:28 Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Previous Message Jan Wieck 1999-01-29 14:15:19 Re: [HACKERS] Postgres Speed or lack thereof