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

Re: [COMMITTERS] pgsql/doc/TODO.detail (alpha default distinct flock fsync function limit null pg_shadow primary)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql/doc/TODO.detail (alpha default distinct flock fsync function limit null pg_shadow primary)
Date: 2000-07-05 00:59:05
Message-ID: 29375.962758745@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> but if one or both postmasters is started without -i then there's got
>> to be some interlock on the Unix socket file.
>> 
>> I don't much like depending on flock for that, since it isn't available
>> everywhere.  The only portable answer is to build a pid-containing
>> interlock file for each socket file, as discussed in the TODO item.

> But the flock code isn't used because the configure test for it is broken,
> and has been broken ever since it was introduced AFAICT. It seems that we
> have been relying on the mere existence of the socket file.

Oooh, no kidding?  That explains why we're still hearing complaints
about the postmaster failing to start up when there's a socket file
left over from a previous run: the code that's supposed to delete an
old socket file is part of the #ifdef HAVE_FCNTL_SETLK path.

(Tries it out ... sure enough, it's broken ...)

The flock is not really needed to protect the port number; it's there
to prevent a second postmaster from deleting the socket file that
belongs to a still-active old postmaster.  But if you have no delete
logic at all, you can't cope with a leftover socket file.

The flock code *did* work at one time; I recall testing it.  Evidently
someone broke the configure test for it later on.

I think the shortest path to a solution is to fix the configure test,
unless you have the ambition to tackle setting up a set of lock files
for port numbers --- which'd require resolving such thorny questions
as where to keep the lock files.  (/tmp is right out, IMHO.)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Philip WarnerDate: 2000-07-05 01:34:34
Subject: Re: zlib for pg_dump
Previous:From: Mike MascariDate: 2000-07-05 00:51:30
Subject: Re: Article on MySQL vs. Postgres

pgsql-committers by date

Next:From: Bruce MomjianDate: 2000-07-05 02:54:36
Subject: Re: [COMMITTERS] pgsql/doc/TODO.detail (alpha default distinct flock fsync function limit null pg_shadow primary)
Previous:From: Tom LaneDate: 2000-07-05 00:25:53
Subject: Re: Memory-context slinging

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