Thread

postgres startup script modification (Linux RedHat)

Daniel Péder <dpeder@infoset.cz> — 1999-09-24T15:26:02Z

This modification eleminates the case described below:
If PostgreSQL (probaly with Linux) was shut down wrong way (power off, any other damage, kill, etc... ) it left opened the file(socket) /tmp/.s.PGSQL.5432 . It is found by Postmaster's next start with message:
===
Starting postgresql service: FATAL: StreamServerPort: bind() failed: errno=98
        Is another postmaster already running on that port?
        If not, remove socket node (/tmp/.s.PGSQL.<portnr>)and retry.
/usr/bin/postmaster: cannot create UNIX stream port
===
so, You are in situation that Linux was completely started, all services are running ok except the postgres - and if You miss it, Your server can be running hours without poperly serving the database. 

= = = = = 

If You find it usefull, make following modification to the file:

	/etc/rc.d/init.d/postgresql

on Your RedHat Linux (other Linux or Unix versions will probably need some changes in locations, filenames etc...)
Begin of the changed lines is marked
         # [B] added by daniel.peder@infoset.cz
End is marked
         # [E] added by daniel.peder@infoset.cz

other text stuff was left for Your better orientation where put the changes...

so here we are:
======================================================
#!/bin/sh
...
...
[ -f /usr/bin/postmaster ] || exit 0

# See how we were called.
case "$1" in
  start)
        # [B] added by daniel.peder@infoset.cz
        echo -n "Checking status of last postgresql service shutdown: "
        psql_socket="/tmp/.s.PGSQL.5432"
        if [ -e $psql_socket -a "`pidof postmaster`" = "" ]; then
            rm -f $psql_socket
            echo "incorrect"
        else
            echo "correct"
        fi
        # [E] added by daniel.peder@infoset.cz

        echo -n "Starting postgresql service: "
        su postgres -c '/usr/bin/postmaster -S -D/var/lib/pgsql'
        sleep 1
        pid=`pidof postmaster`
        echo -n "postmaster [$pid]"
        touch /var/lock/subsys/postmaster
        echo
        ;;
  stop)
        echo -n "Stopping postgresql service: "
        killproc postmaster
        sleep 2
        rm -f /var/lock/subsys/postmaster
        echo
        ;;...
...
======================================================


--

dpeder@infoset.cz
Daniel Peder
http://shop.culture.cz
>From bouncefilter  Fri Sep 24 11:28:08 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
	[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA25656
	for <pgsql-hackers@postgreSQL.org>;
	Fri, 24 Sep 1999 11:27:41 -0400 (EDT)
	(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
	by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
	id SAA18100; Fri, 24 Sep 1999 18:30:11 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
	by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
	SAA00747; Fri, 24 Sep 1999 18:27:36 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37EB9867.E45479C@albourne.com>
Date: Fri, 24 Sep 1999 18:27:36 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Hannu Krosing <hannu@tm.ee>, Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
	<37E87542.2F8ADA4A@albourne.com>
	<37E8F672.9B98E9BF@alumni.caltech.edu>
	<37E9E490.1CD9623B@albourne.com>
	<37EA31BC.A18A31EE@alumni.caltech.edu>
	<37EA3723.B513E03@albourne.com>
	<37EA459C.29E2B38D@alumni.caltech.edu>
	<37EA5361.59EC106D@albourne.com> <37EA95FB.F6DF530A@tm.ee>
	<37EB0AC6.C608E1A2@albourne.com>
	<37EB88E0.24A45661@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:
> 
> attypmod has been modified recently to contain two fields (each of 16
> bits) in a backward-compatible way. It can hold the size *and*
> precision of the numeric data types, and presumably should be used in
> a similar manner for your bit type.
> 
> The problem is that you need another field which contains a length in
> bit units. Assuming that the second field in attypmod can't be used
> for this purpose, then istm that you will want to add a field to the
> data type itself. The character types have:
> 
>   length - total size of data, in bytes (4 bytes)
>   data   - body
> 
> and you might have
> 
>   length - total size of data, in bytes (4 bytes)
>   blen   - total size of data, in bits (4 bytes)
>   data   - body

OK, I just saw th email from Tom Lane as well. So I will use attypmod as
the length of the bit string in bits, and use an additional byte, as
suggested here, for the actual length.

Jose recommended looking at the Ocelot database and I got it down. Turns
out they have a real big problem with the output of bit strings, but at
least I could figure out how they do the ordering. Looks as if it is
lexicographically from the least significant bit, i.e.

   B'1' > B'10' > B'1100'

the only surprising thing was that they then have B'1000' > B'01000',
and my reading of the SQL standard says that it should be the other way
round. So I will just do the comparison from the least significant bit.

Cheers,

Adriaan