Magnus Hagander wrote:
Alvaro Herrera wrote:
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the
return value idea, let me know.
So is this a patch we want applied?
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the return
value idea, let me know.
So is this a patch we want applied?
--
Alvaro Herrera
Alvaro Herrera wrote:
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the
return value idea, let me know.
So is this a patch we want applied?
Please see my other thread about libpq
Magnus Hagander wrote:
Alvaro Herrera wrote:
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the
return value idea, let me know.
So is this a patch we want applied?
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the
return value idea, let me know.
Here's a version of this patch that doesn't use malloc - instead, I had
to change the callers to it a
Andrew Chernow wrote:
Magnus Hagander wrote:
It changes the behavior when the pointer passed in is invalid from
crash to silent working, right?
Correct, it a Habit. I sub-consciously write code that checks
pointers. We can remove the pointer checks and let the thing dump
core if
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
The attached patch replaces the win32 mutex calls with critical
section calls. The change will not affect the behavior of the
windows pthread_xxx functions.
Why have you defined the lock/unlock functions
Merlin Moncure wrote:
On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander
[EMAIL PROTECTED] wrote:
Andrew Chernow wrote:
I noticed several months ago, and came across it again today,
that libpq's pthread-win32.c implementation is using CreateMutex
rather than CRITICAL_SECTION.
Andrew Chernow wrote:
I noticed several months ago, and came across it again today, that
libpq's pthread-win32.c implementation is using CreateMutex rather
than CRITICAL_SECTION. CreateMutex is like a semaphore in that it is
designed to be accessible via name system-wide. Even when you
Magnus Hagander wrote:
It changes the behavior when the pointer passed in is invalid from
crash to silent working, right?
Correct, it a Habit. I sub-consciously write code that checks pointers.
We can remove the pointer checks and let the thing dump core if people
prefer.
Which brings up
On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Andrew Chernow wrote:
I noticed several months ago, and came across it again today, that
libpq's pthread-win32.c implementation is using CreateMutex rather
than CRITICAL_SECTION. CreateMutex is like a semaphore in
Andrew Chernow [EMAIL PROTECTED] writes:
The attached patch replaces the win32 mutex calls with critical section
calls. The change will not affect the behavior of the windows
pthread_xxx functions.
Why have you defined the lock/unlock functions as willing to fall
through silently if handed
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
The attached patch replaces the win32 mutex calls with critical section
calls. The change will not affect the behavior of the windows
pthread_xxx functions.
Why have you defined the lock/unlock functions as willing to fall
through
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the return
value idea, let me know.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/port/pthread-win32.h
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the return
value idea, let me know.
A more graceful solution would
Andrew Chernow [EMAIL PROTECTED] writes:
A more graceful solution would be to print something to stderr and then
exit.
stderr doesn't exist, or point to a useful place, in many environments.
And a forced exit() is no better than a crash for most purposes.
I don't think libpq should core dump
On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
A more graceful solution would be to print something to stderr and then
exit.
stderr doesn't exist, or point to a useful place, in many environments.
And a forced exit() is no better than a
daveg wrote:
On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
A more graceful solution would be to print something to stderr and then
exit.
stderr doesn't exist, or point to a useful place, in many environments.
And a forced exit() is no
18 matches
Mail list logo
