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
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
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 t
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 Herrerahttp://www
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
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_SE
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/
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
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 bett
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 bett
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
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
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
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 si
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 han
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 sema
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 u
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
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 don't
give it a name, thus b
19 matches
Mail list logo
