pgsql/doc/TODO.detail (alpha default distinct flock fsync function limit null pg_shadow primary)

On Tue, 4 Jul 2000, Bruce Momjian - CVS wrote:

Removed Files:
alpha default distinct flock fsync function limit null
pg_shadow primary

What are we going to do with the flock? Remove it? I asked about this
yesterday, I guess it's not useful anymore.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

On Tue, 4 Jul 2000, Bruce Momjian - CVS wrote:

Removed Files:
alpha default distinct flock fsync function limit null
pg_shadow primary

What are we going to do with the flock? Remove it? I asked about this
yesterday, I guess it's not useful anymore.

Well, we have the postmaster pid thing working now. Is there an issue
with flock() I have forgotten?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

eisentrp@csis.gvsu.edu writes:

On Tue, 4 Jul 2000, Bruce Momjian - CVS wrote:

Removed Files:
alpha default distinct flock fsync function limit null
pg_shadow primary

What are we going to do with the flock? Remove it? I asked about this
yesterday, I guess it's not useful anymore.

It still is, because the $PGDATA pid file only guards against starting
two postmasters in the same data directory. You still need some lock
against starting two postmasters on the same port number. The TCP
socket address can take care of itself, 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.

It was premature of Bruce to delete the flock TODO file, since there is
still a lot of undone stuff in there concerning both this issue and
moving the Unix-socket file to a safer place than /tmp.

regards, tom lane

PS: Hey Bruce, mail directly to your personal address
pgman@candle.pha.pa.us has been bouncing since Sunday.

Bruce Momjian writes:

On Tue, 4 Jul 2000, Bruce Momjian - CVS wrote:

Removed Files:
alpha default distinct flock fsync function limit null
pg_shadow primary

What are we going to do with the flock? Remove it? I asked about this
yesterday, I guess it's not useful anymore.

Well, we have the postmaster pid thing working now. Is there an issue
with flock() I have forgotten?

We still have the locking code in there, together with the broken
configure test. See my message from the other day ("fcntl(F_SETLK)") --
should we just remove all that stuff?

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

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.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut <peter_e@gmx.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

I will add the flock TODO.detail file for people to review.

[ Charset ISO-8859-1 unsupported, converting... ]

Bruce Momjian writes:

On Tue, 4 Jul 2000, Bruce Momjian - CVS wrote:

Removed Files:
alpha default distinct flock fsync function limit null
pg_shadow primary

What are we going to do with the flock? Remove it? I asked about this
yesterday, I guess it's not useful anymore.

Well, we have the postmaster pid thing working now. Is there an issue
with flock() I have forgotten?

We still have the locking code in there, together with the broken
configure test. See my message from the other day ("fcntl(F_SETLK)") --
should we just remove all that stuff?

--
Peter Eisentraut Sernanders v?g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

eisentrp@csis.gvsu.edu writes:

On Tue, 4 Jul 2000, Bruce Momjian - CVS wrote:

Removed Files:
alpha default distinct flock fsync function limit null
pg_shadow primary

What are we going to do with the flock? Remove it? I asked about this
yesterday, I guess it's not useful anymore.

It still is, because the $PGDATA pid file only guards against starting
two postmasters in the same data directory. You still need some lock
against starting two postmasters on the same port number. The TCP
socket address can take care of itself, 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.

It was premature of Bruce to delete the flock TODO file, since there is
still a lot of undone stuff in there concerning both this issue and
moving the Unix-socket file to a safer place than /tmp.

OK, I have re-added TODO.detail, and re-added the TODO item.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026