Re: On file locking

Mmy problem is freebsd getting totally loaded at which point it sends kills
to various processes. This sometime seems to end up with several actual
postmasters running, and none of them working.

Better existing process detection would help that greatly I'm sure.

Chris

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Kevin Brown
> Sent: Friday, 31 January 2003 11:24 AM
> To: PostgreSQL Development
> Subject: [HACKERS] On file locking
>
>
> I've been looking at the PID file creation mechanism we currently use.
> It goes through a loop in an attempt to create the PID file, and if
> one is there it attempts to remove it if the PID it contains no longer
> exists (there are checks for shared memory usage as well).
>
> This could be cleaned up rather dramatically if we were to use one of
> the file locking primitives supplied by the OS to grab an exclusive
> lock on the file, and the upside is that, when the locking code is
> used, the postmaster would *know* whether or not there's another
> postmaster running, but the price for that is that we'd have to eat a
> file descriptor (closing the file means losing the lock), and we'd
> still have to retain the old code anyway in the event that there is no
> suitable file locking mechanism to use on the platform in question.
>
> The first question for the group is: is it worth doing that?
>
> The second question for the group is: if we do indeed decide to do
> file locking in that manner, what *other* applications of the OS-level
> file locking mechanism will we have? Some of them allow you to lock
> sections of a file, for instance, while others apply a lock on the
> entire file. It's not clear to me that the former will be available
> on all the platforms we're interested in, so locking the entire file
> is probably the only thing we can really count on (and keep in mind
> that even if an API to lock sections of a file is available, it may
> well be that it's implemented by locking the entire file anyway).
>
> What I had in mind was implementation of a file locking function that
> would take a file descriptor and a file range. If the underlying OS
> mechanism supported it, it would lock that range. The interesting
> case is when the underlying OS mechanism did *not* support it. Would
> it be more useful in that case to return an error indication? Would
> it be more useful to simply lock the entire file? If no underlying
> file locking mechanism is available, it seems obvious to me that the
> function would have to always return an error.
>
>
> Thoughts?
>
>
>
> --
> Kevin Brown kevin(at)sysexperts(dot)com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>