Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
How about the typical answer on Windows ? Create an invisible Window with an Event Handler and pass it a windows message ? Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
Neil Conway said: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> In normal operation the only thing that should be signalling a >> backend is the postmaster. > > Oh? What about LISTEN/NOTIFY? > er, yeah. *self-lart* +" ... or another backend" cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
Neil Conway kirjutas K, 17.12.2003 kell 00:37: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > In normal operation the only thing that should be signalling a > > backend is the postmaster. > > Oh? What about LISTEN/NOTIFY? IIRC cancelling queries is done by making a connection to a new backend and then this backend signalls the one needing to have its query cancelled. Or is the cancelling done by postmaster without starting a new backend ? -- Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
Andrew Dunstan <[EMAIL PROTECTED]> writes: > In normal operation the only thing that should be signalling a > backend is the postmaster. Oh? What about LISTEN/NOTIFY? -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
Magnus Hagander wrote: Absolutely, but there are other signals to send, no? Or you might want to send a signal directly to a backend (to cancel for example), as you can do on Unix. In normal operation the only thing that should be signalling a backend is the postmaster. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
> -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 16, 2003 7:53 AM > To: Andrew Dunstan; PostgreSQL-development; pgsql-hackers-win32 > Subject: Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch > > > > > If you need a response once it has actually run, then the > > main thread > > > needs to do signal polling now and then. This has the bad > > sideeffect > > > that the main thread will block completely until the signal is > > > delivered, which might be a while. > > > > > > I don't know what the semantics are for kill() on unix > > there? And if > > > it is sync, does postgresql actually need that property? > > > > > > > kill() should return success upon the signal being queued, as I > > understand it - i.e. no sync. > > Ok. That makes things a lot easier. THen it's just the > question of how fast we need to react. > > > > > All this kind of answers my original question, by pointing > > out the need > > to poll one way or another, which is why I suggested that signal > > emulation might be messy, and more complicated than the > > fork/exec case. > > > That definitly makes it more complicated. However, IIRC the > thread will > enter an "alerable state" at least for network I/O, and probably for > disk I/O. Can't seem to find a reference to this, though. If you use > queued user APCs (using QueueUserAPC()), from a separate > signal-handling > thread, this should dispatch the signal handlers *fairly* fast. The > question is if "fairly fast" is good enough, or if "really fast" is > needed? > > In that case, you might have to work either with poll-really-often > (ickk), or using manual thread exceptions (raelly messy). > > It shouldn't need to be *too* messy, if you can live with possible > slowdowns (assuming the thread does go alertable on blocking I/O). > Possibly add a WaitForSingleObject() at some place in a loop > to force it > there in some cases. > > Looking some more on the os-fix2.cpp file (I read the thing > as OS2 fix, > and thus ignored it), it seems they fire all signal handlers > on a thread > of their own. Is the backend threadsafe enough that that is > safe? If so, > that would do away with the nede to use QueueUserAPC() to > make the call > execute on the main thread. By using events you don't have to poll at all. You are waiting on the event. A signal fires the event. It is also possible to add as many signal types as you like, even beyond the standard UNIX batch if it suits your fancy. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
> > If you need a response once it has actually run, then the > main thread > > needs to do signal polling now and then. This has the bad > sideeffect > > that the main thread will block completely until the signal is > > delivered, which might be a while. > > > > I don't know what the semantics are for kill() on unix > there? And if > > it is sync, does postgresql actually need that property? > > > > kill() should return success upon the signal being queued, as I > understand it - i.e. no sync. Ok. That makes things a lot easier. THen it's just the question of how fast we need to react. > All this kind of answers my original question, by pointing > out the need > to poll one way or another, which is why I suggested that signal > emulation might be messy, and more complicated than the > fork/exec case. That definitly makes it more complicated. However, IIRC the thread will enter an "alerable state" at least for network I/O, and probably for disk I/O. Can't seem to find a reference to this, though. If you use queued user APCs (using QueueUserAPC()), from a separate signal-handling thread, this should dispatch the signal handlers *fairly* fast. The question is if "fairly fast" is good enough, or if "really fast" is needed? In that case, you might have to work either with poll-really-often (ickk), or using manual thread exceptions (raelly messy). It shouldn't need to be *too* messy, if you can live with possible slowdowns (assuming the thread does go alertable on blocking I/O). Possibly add a WaitForSingleObject() at some place in a loop to force it there in some cases. Looking some more on the os-fix2.cpp file (I read the thing as OS2 fix, and thus ignored it), it seems they fire all signal handlers on a thread of their own. Is the backend threadsafe enough that that is safe? If so, that would do away with the nede to use QueueUserAPC() to make the call execute on the main thread. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Have you looked at the CONNX signal code on the Win32 page:
> >
> > http://momjian.postgresql.org/main/writings/pgsql/win32.html
> >
> >It uses shared memory and events.
> >
> >
> >
>
> Yes, and I just did again. I guess I must be missing something, though -
> I don't see what in that code causes the signalled process to call the
> handler corresponding to the signal. Maybe I'm just a little brain dead
> today ...
In the CONNX code for kill() I see:
sprintf(szEventName, "CONNX_SIGNAL_%x", (int) lPID);
sprintf(szSharedMemoryName, "CONNX_SMEM_%x", (int) lPID);
hSharedMemory = OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE, szSharedMemoryName);
if (hSharedMemory) {
/* Call the signal handle for that process.. */
void *pData = MapViewOfFile(hSharedMemory, FILE_MAP_ALL_ACCESS, 0,
0, sizeof(int));
if (pData) {
int nReturn;
HANDLE hProcessHandle;
DWORD ExitCode;
*(int *) pData = nSignal;
UnmapViewOfFile(pData);
/* Open the event handle of the other process */
hEvent = OpenEvent(EVENT_MODIFY_STATE | SYNCHRONIZE, FALSE, szEventName);
hProcessHandle = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, lPID);
if (hEvent) {
SetEvent(hEvent);
/* Wait for Event to be processed. */
do {
nReturn = WaitForSingleObject(hEvent, 0);
Now, I am no Win32 programmer, but the mixture of OpenFileMapping() and
OpenEvent() looked promising. :-)
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
