That's not workable, unless you want to assume that nothing on the
system except Postgres uses SysV semaphores. Otherwise something else
could randomly gobble up the semid you want to use. I don't care very
much for requiring a distinct semid to be hand-specified for each
postmaster on a
On Thursday 25 May 2006 14:35, korry wrote:
That's not workable, unless you want to assume that nothing on the
system except Postgres uses SysV semaphores. Otherwise something else
could randomly gobble up the semid you want to use. I don't care very
much for requiring a distinct semid
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
What I don't get is why everybody think that because one solution doesn't fit
all needs on all platforms(or NFS), it shouldn't be implemented on those
platforms it *does* work on.
(1) Because we're not really interested in supporting multiple
On Tuesday 23 May 2006 19:36, Tom Lane wrote:
Adis Nezirovic [EMAIL PROTECTED] writes:
Well, maybe you could tweak postgres startup script, add check for post
master (either 'pgrep postmaster' or 'ps -axu | grep [p]ostmaster'), and
delete pid file on negative results.
This is exactly what
On Wednesday 24 May 2006 11:36, Andreas Joseph Krogh wrote:
On Tuesday 23 May 2006 19:36, Tom Lane wrote:
Adis Nezirovic [EMAIL PROTECTED] writes:
Well, maybe you could tweak postgres startup script, add check for post
master (either 'pgrep postmaster' or 'ps -axu | grep [p]ostmaster'),
On 5/24/06, Andreas Joseph Krogh [EMAIL PROTECTED] wrote:
My PG is not started with startup-scripts, but with this command:
pg_ctl -D $PGDATA -l $PGDIR/log/logfile-`date +%Y-%m-%d`.log start
... and manually after login, ie. not at boot-time.
I'd suggest trying to fix your Linux-install
On Wednesday 24 May 2006 21:03, korry wrote:
I'm sure there's a good reason for having it the way it is, having so
many smart knowledgeable people working on this project. Could someone
please explain the rationale of the current solution to me?
We've ignored Andreas' original question.
On Wednesday 24 May 2006 20:52, Andrej Ricnik-Bay wrote:
On 5/24/06, Andreas Joseph Krogh [EMAIL PROTECTED] wrote:
My PG is not started with startup-scripts, but with this command:
pg_ctl -D $PGDATA -l $PGDIR/log/logfile-`date +%Y-%m-%d`.log start
... and manually after login, ie.
I'm sure there's a good reason for having it the way it is, having so many
smart knowledgeable people working on this project. Could someone please
explain the rationale of the current solution to me?
We've ignored Andreas' original question. Why not use a lock to indicate that the
On Wednesday 24 May 2006 21:03, korry wrote:
I'm sure there's a good reason for having it the way it is, having so
many smart knowledgeable people working on this project. Could someone
please explain the rationale of the current solution to me?
We've ignored Andreas' original
Certainly on all platforms there must be *some* locking primitive. We
just need to figure out the appropiate parameters to fcntl() or flock()
or lockf() on each.
Right.
The Win32 API for locking seems mighty strange to me.
Linux/Unix byte locking is advisory (meaning that one
Alvaro Herrera wrote:
korry wrote:
The only platform (although certainly not a minor issue) that I can
think of that would have a portability issue would be Win32. You can't
even read a locked byte in Win32. I usually solve that problem by
locking a byte past the end of the file (which is
korry wrote:
The Win32 API for locking seems mighty strange to me.
Linux/Unix byte locking is advisory (meaning that one lock can block
another lock, but it can't block a read).
No -- it is advisory meaning that a process that does not try to acquire
the lock is not locked out. You can
Alvaro Herrera [EMAIL PROTECTED] writes:
Certainly on all platforms there must be *some* locking primitive. We
just need to figure out the appropiate parameters to fcntl() or flock()
or lockf() on each.
Quite aside from the hassle factor of needing to deal with N variants of
the syscalls, I'm
Andrew Dunstan wrote:
We use file locking on Win32 (and on all other platforms) in the
buildfarm ... it's done from perl so maybe perl does some magic under
the hood. The call looks just the same, and works fine on W32, I
believe. It is roughly:
use Fcntl qw(:flock);
Alvaro Herrera wrote:
Note that it may fail! This seems to indicate that some platforms do
not provide either locking mechanism.
(Which means the whole discussion is a waste of time)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Note that it may fail! This seems to indicate that some platforms do
not provide either locking mechanism.
(Which means the whole discussion is a waste of time)
Umm, no, I don't think so. It will block instead of failing unless you
On Wed, 2006-05-24 at 16:34 -0400, Alvaro Herrera wrote:
korry wrote:
The Win32 API for locking seems mighty strange to me.
Linux/Unix byte locking is advisory (meaning that one lock can block
another lock, but it can't block a read).
No -- it is advisory meaning that a process that
Alvaro Herrera [EMAIL PROTECTED] writes:
Certainly on all platforms there must be *some* locking primitive. We
just need to figure out the appropiate parameters to fcntl() or flock()
or lockf() on each.
I use lockf() (not fcntl() or flock()) on every platform other than Win32. Of
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Note that it may fail! This seems to indicate that some platforms do
not provide either locking mechanism.
(Which means the whole discussion is a waste of time)
Umm, no, I don't think so. It will block instead of
korry [EMAIL PROTECTED] writes:
However, Tom may be correct about NFS locking, but I guess I'm surprised
that anyone would care :-)
Whether we think it's a real good idea or not, *plenty* of people run
databases across NFS. We can't blow off that set of users.
regards,
korry wrote:
I think the next question is -- how would the lock interface be used?
We could acquire an exclusive lock on postmaster start (to make sure no
backend is running), then reduce it to a shared lock. Every backend
would inherit the shared lock. But the lock exchange is not
You never need to reduce it to a shared lock. On postmaster startup,
try to lock the sentinel byte (one byte past the end-of-file). If you
can lock it, you know that no other postmaster has that byte locked. If
you can't lock it, another postmaster is running. It is an atomic
korry [EMAIL PROTECTED] writes:
Well, it fails in the safe direction: the postmaster may occasionally
refuse to start when it should, but it won't ever start when it should
not. It appears to me that anything relying on file locking will tend
to fail in the other direction, and that's not
korry wrote:
You never need to reduce it to a shared lock. On postmaster startup,
try to lock the sentinel byte (one byte past the end-of-file). If you
can lock it, you know that no other postmaster has that byte locked. If
you can't lock it, another postmaster is running. It is an
We already have two platforms that don't use the SysV semaphore
interface, and even on ones that have it, I wouldn't want to assume they
all support SEM_UNDO.
Which platforms, just out of curiousity? I assume that Win32 is one of them.
But aside from any portability issues, ISTM this
korry [EMAIL PROTECTED] writes:
Isn't that sort of like saying that if a postmaster.pid file exists, it
must have been written by a postmaster? Pick a semaphore id and
dedicate it to postmaster exclusion.
That's not workable, unless you want to assume that nothing on the
system except
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
I've experienced several times that PG has died somehow and the
postmaster.pid
file still exists 'cause PG hasn't had the ability to delete it upon proper
shutdown. Upon start-up, after such an incidence, PG tells me another PG is
running and
On Tuesday 23 May 2006 17:54, Tom Lane wrote:
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
I've experienced several times that PG has died somehow and the
postmaster.pid file still exists 'cause PG hasn't had the ability to
delete it upon proper shutdown. Upon start-up, after such an
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
On Tuesday 23 May 2006 17:54, Tom Lane wrote:
The postmaster does check to see whether the PID mentioned in the file
is still alive, so it's not that easy for the above to happen. If you
can provide details of a scenario where a failure is
On Tue, May 23, 2006 at 05:23:16PM +0200, Andreas Joseph Krogh wrote:
Hi all.
I've experienced several times that PG has died somehow and the
postmaster.pid
file still exists 'cause PG hasn't had the ability to delete it upon proper
shutdown. Upon start-up, after such an incidence, PG
Adis Nezirovic [EMAIL PROTECTED] writes:
Well, maybe you could tweak postgres startup script, add check for post
master (either 'pgrep postmaster' or 'ps -axu | grep [p]ostmaster'), and
delete pid file on negative results.
This is exactly what you should NOT do.
A start script that thinks it
On Tue, May 23, 2006 at 01:36:41PM -0400, Tom Lane wrote:
This is exactly what you should NOT do.
A start script that thinks it is smarter than the postmaster is almost
certainly wrong. It is certainly dangerous, too, because auto-deleting
that pidfile destroys the interlock against having
33 matches
Mail list logo
