Re: [pgsql-hackers-win32] Win32 signal code - first try - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: [pgsql-hackers-win32] Win32 signal code - first try
Date
Msg-id 303E00EBDD07B943924382E153890E5434AA51@cuthbert.rcsinc.local
Whole thread Raw
List pgsql-hackers
Claudio Natoli wrote:
> FWIW, in a multithreaded version of postgres I'm fooling around with,
I
> replaced the recv call (where backends spend most of their time
waiting)
> which a select(small timeout)/SleepEx(0) "busy" loop, which calls to
recv
> when ready. Works just fine.

Ok, that makes perfect sense.  Simply checking pending signals in this
loop and just after a command is received will catch most of them, and
provide a suitable testing platform.

IMO, it's time for a second run of the code, and a functional test which
simulates the command processing loop which should include:

1. setjmp/longjmp stack manipulation (i.e. ELOG)
2. in process/out of process generates signals
3. all thread mechanisms.

under heavy load conditions.
We should be especially watching for deadlocks, stack corruption, and
memory leaks...    If everything goes ok, I think we'll have a good
'proof of concept' signaling mechanism.  After that, its time to start
submitting patches to the hackers for review...

Merlin



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Encoding problems in PostgreSQL with XML data
Next
From: Tom Lane
Date:
Subject: Re: LWLock/ShmemIndex startup question