Skip site navigation (1) Skip section navigation (2)

RH 6.1, PostgreSQL 7.0.2, ipcclean madness

From: Roland Roberts <roberts(at)panix(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: RH 6.1, PostgreSQL 7.0.2, ipcclean madness
Date: 2000-08-04 01:36:49
Message-ID: m2aeet24em.fsf@tycho.rlent.pnet (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers

I have finally needed to use ipcclean.  I recently built HaruspeX 4.0,
an application for managing pictures which uses Postgres, and while
asking to delete a table, it hung.  I had the app in the debugger, and
I found it was hung on the database call itself.  So, after waiting a
couple of hours, I decided to bounce postgres by running the init
script.  HaruspeX dutifully reported that the backend had closed the
connection.  However, postgres did not come back up.  I found two
processes running as postgres:

532 root> ps -efw | grep post
postgres 26171     1  0 00:02 ?        00:01:04 /usr/bin/postgres localhost roland family idle
postgres 26188     1  0 00:03 ?        00:00:00 /usr/bin/postgres localhost roland family idle
root      6681 20510  0 21:20 pts/2    00:00:00 grep post

When I attempted to run pgctl directly, it reported a problem with
semaphore space, so I tried to run ipcclean.  It kept reporting I had
a postmaster running when I couldn't find it.  Finally, I had a look
at the script.  Oops, it has this line:

    if ps x | grep -s 'postmaster' >/dev/null 2>&1 ; then

But consider:

557 root> ps x | grep -s 'postmaster'
 7084 pts/2    S      0:00 grep -s postmaster

So, it keeps seeing its test instead of the real postmaster.  How about

    ps x | grep -s postmaster | grep -v grep


- -- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                    Unix Software Solutions
roberts(at)panix(dot)com                      76-15 113th Street, Apt 3B
rbroberts(at)acm(dot)org                          Forest Hills, NY 11375

Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface


In response to

pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-08-04 02:00:52
Subject: RE: Anyone particularly wedded to func_tlist mechanism?
Previous:From: Philip WarnerDate: 2000-08-04 01:29:28
Subject: Re: [HACKERS] pg_dump/restore to convert BLOBs to LZTEXT (optional!)

pgsql-bugs by date

Next:From: Philip WarnerDate: 2000-08-04 13:26:07
Subject: Re: pg_dump problem
Previous:From: Paulo Roberto SiqueiraDate: 2000-08-04 01:05:28
Subject: pg_dump problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group