Re: postgresql-[any version] from FreeBSD ports - startup

From: Ruslan A Dautkhanov <rusland(at)scn(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: postgresql-[any version] from FreeBSD ports - startup
Date: 2006-05-16 06:19:51
Message-ID: 44696F07.8080308@scn.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello !

Tom Lane wrote:

>Ruslan A Dautkhanov <rusland(at)scn(dot)ru> writes:
>
>
>>Server rebooted occasionally after power failure.
>>And I have stale postmaster.pid file, so postmaster didn't start with error
>> bill postgres[600]: [1-1] FATAL: file "postmaster.pid" already exists
>>
>>
>
>You probably need a newer postgres version (you didn't say what you are
>using) and/or a more carefully written start script.
>
>
I hane FreeBSD 6.0-STABLE
and PostgreSQL 8.1.3 on i386-portbld-freebsd6.0, compiled by GCC cc
(GCC) 3.4.4 [FreeBSD].

As I said, PostgreSQL was built from freebsd ports, so startup script is
also from ports...

>Your proposed change in the start script is useless --- do you think the
>postmaster doesn't check that already? Furthermore, it's actually
>dangerous for reasons we need not get into here; suffice to say that
>automated removal of that lock file is NOT a good idea.
>
>
I know that this is not a good idea, but if it'll keep startup process
stable,
it have rights to exist...

>The problem comes up when the startup timing is just different enough
>that the PID belonging to the postmaster in the previous boot cycle now
>belongs to the shell that's launching it. The postmaster sees a live
>process of the correct userid (ie, postgres) and has to assume that
>that's a pre-existing postmaster.
>
>We've fixed this in recent releases by having the postmaster also check
>for a match to its parent process ID (getppid). The care in the start
>script comes because this only works for one level up. Therefore, you
>can't "su -c pg_ctl start ..." because that would create three levels of
>postgres-owned processes (shell, pg_ctl, postmaster) and if the PID
>count is off by 2 instead of 1 then we still lose. You have to invoke
>the postmaster directly, "su -c postmaster ...". (Hm, actually it might
>work to do "su -c 'exec pg_ctl ...'" ... I have not tried that.)
>
>
Thank you for the information, I'll play with it and try to avoid big
if-if-if block in the startup script...

--
best regards,
Ruslan A Dautkhanov

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Exner 2006-05-16 08:04:22 BUG #2440: TEMP TABLES in Postgres 8.1.3
Previous Message Tom Lane 2006-05-16 03:49:49 Re: [BUGS] BUG #2429: Explain does not report object's schema