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


From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: Barry Lind <blind(at)xythos(dot)com>,pgsql-hackers-win32(at)postgresql(dot)org, Max Dunn <mdunn(at)xythos(dot)com>
Subject: Re:
Date: 2004-08-24 14:05:43
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers-win32

Dave Page wrote:

>     ------------------------------------------------------------------------
>     *From:* pgsql-hackers-win32-owner(at)postgresql(dot)org
>     [mailto:pgsql-hackers-win32-owner(at)postgresql(dot)org] *On Behalf Of
>     *Dave Page
>     *Sent:* 20 August 2004 20:57
>     *To:* Barry Lind; pgsql-hackers-win32(at)postgresql(dot)org
>     *Cc:* Max Dunn
>     *Subject:* Re: [pgsql-hackers-win32]
>     I've been thinking about this problem as well, and think you might
>     just be on to something here. I'll look into this some more...
> The correct way to do this is MoveFileEx("", NULL, 
> MOVEFILE_DELAY_UNTIL_REBOOT);. This /should/ write a registry entry to 
> tell the system to delete the file at reboot. Unfortunately, it seems 
> that this is an administrator-only operation which of course means it 
> won't work when run under the postgresql service account.

I think we're on the wrong track here. If there is a pid file then the 
postmaster will try to see if the process is running by calling 
kill(pid,0) - see backend/utils/init/miscinit.c.

However, on Windows we simulate kill(), and always return EINVAL if the 
signal <= 0 (see port/kill.c). ISTM the correct solution would be to 
implement the effect of kill(pid,0) in port/kill.c, presumably by a call 
to some native Windows function that gives you the process info for a 
given pid.



In response to


pgsql-hackers-win32 by date

Next:From: Alvaro HerreraDate: 2004-08-24 14:09:32
Subject: Re: pgsql-server: Update that 8.0 will support MS Win
Previous:From: Marc G. FournierDate: 2004-08-24 11:50:44
Subject: Re: pgsql-server: Update that 8.0 will support MS Win

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