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 multipl
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
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 m
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 P
> > > 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
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 w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Well, you are wrong here. We _want_ every backend to hold a shared
> lock. We need to stop a postmaster from starting if there is a backend
> running that was started by a no-longer-running postmaster.
Note that we currently rely on checking for SysV
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
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'
> 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
> ope
> What we currently have in place is not bulletproof.
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 direc
korry <[EMAIL PROTECTED]> writes:
> What we currently have in place is not bulletproof.
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 ten
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 n
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.
regar
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 i
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
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 t
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
r
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, Cons
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);
> open($lockf
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,
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 ca
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 p
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 lo
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 portable).
Certainly
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
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 po
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 afte
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 quest
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-instal
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]ostm
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 ex
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 hav
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
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,
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 i
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
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
> runni
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 tells me another PG is
running and that I either have to shut down the other in
39 matches
Mail list logo
