I see these in the patch:
/* Setup _THREAD_SAFE and _POSIX_PTHREAD_SEMANTICS, this will disappear
* in time once tests to determine correct compiler switches for threads
* are added to configure.
*/
#if !defined _THREAD_SAFE
#define
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Paul Ramsey [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, June 14, 2003 1:02 AM
Subject: Re: [HACKERS] Compiling Win32
You should be able to compile, but not link the backend.
But it does not ! At least not
I have not tested the Win32 compile in a few weeks, so it is possible it
is broken at this point. It will not run because we need exec()
handling that Jan is working on, and signal stuff.
---
Darko Prenosil wrote:
-
Hi Jan,
Do you have an ETA for this?
:-)
Regards and best wishes,
Justin Clift
Bruce Momjian wrote:
I have not tested the Win32 compile in a few weeks, so it is possible it
is broken at this point. It will not run because we need exec()
handling that Jan is working on, and signal stuff.
Justin Clift wrote:
Hi Jan,
Do you have an ETA for this?
I was going to report the Win32 status this week. As you know, I had to
leave Win32 to catch up on email. The two big items left are exec()
handlling and signals. If I can get those in by July 1, I can continue
cleanup during beta
- Original Message -
From: Darko Prenosil [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]; Paul Ramsey
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 13, 2003 5:12 PM
Subject: Re: [HACKERS] Compiling Win32
- Original Message -
From: Bruce Momjian [EMAIL
Bruce Momjian wrote:
Justin Clift wrote:
Hi Jan,
Do you have an ETA for this?
I was going to report the Win32 status this week. As you know, I had to
leave Win32 to catch up on email. The two big items left are exec()
handlling and signals. If I can get those in by July 1, I can continue
On Friday 13 June 2003 15:29, Lamar Owen wrote:
It is or was a Linux kernel problem. The 2.2 kernel required double swap
space, even though it wasn't well documented. Early 2.4 kernels also
required double swap space, and it was better documented. Current Red Hat
2.4 kernels, I'm not sure
Justin Clift wrote:
Bruce Momjian wrote:
Justin Clift wrote:
Hi Jan,
Do you have an ETA for this?
I was going to report the Win32 status this week. As you know, I had to
leave Win32 to catch up on email. The two big items left are exec()
handlling and signals. If I can get
Bruce Momjian wrote:
Justin Clift wrote:
Bruce Momjian wrote:
Justin Clift wrote:
Hi Jan,
Do you have an ETA for this?
I was going to report the Win32 status this week. As you know, I had to
leave Win32 to catch up on email. The two big items left are exec()
handlling and signals. If I
Justin Clift wrote:
I was going to report the Win32 status this week. As you know, I had to
leave Win32 to catch up on email. The two big items left are exec()
handlling and signals. If I can get those in by July 1, I can continue
cleanup during beta and perhaps have a patch that people can
The trouble with this advice is that if I am an SA wanting to run a DBMS
server, I will want to run a kernel supplied by a vendor, not an arbitrary
kernel released by a developer, even one as respected as Alan Cox.
andrew
- Original Message -
From: Lamar Owen [EMAIL PROTECTED]
To: Nigel
Then, I'm all ears and ready to help if I can
On Fri, 13 Jun 2003, The Hermit Hacker wrote:
Date: Fri, 13 Jun 2003 18:21:48 -0300 (ADT)
From: The Hermit Hacker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED]
Subject: Re: [HACKERS] Mirro updates
On Fri, 13
Here is the final patch for libpq threading. It adds the bulk of your
patch, plus some cleanups on calling reentrant functions.
We now have these per-platform configure settings:
linux*) THREAD_CFLAGS=-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS
This patch handles two more gethostbyname calls.
---
Lee Kindness wrote:
Content-Description: message body text
Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
files for src/interfaces/libpq.
http://lwn.net/Articles/4628/ has this possibly useful info:
---
So what is strict VM overcommit? We introduce new overcommit policies
that attempt to never succeed an allocation that can not be fulfilled by
the backing store and consequently never OOM. This is achieved through
Kurt Roeckx wrote:
On Sat, Jun 14, 2003 at 02:20:44PM -0400, Bruce Momjian wrote:
This patch handles two more gethostbyname calls.
[...]
diff -c -c -r1.24 fe-secure.c
*** src/interfaces/libpq/fe-secure.c14 Jun 2003 17:49:54 - 1.24
---
On Sat, 14 Jun 2003, Andrew Dunstan wrote:
The trouble with this advice is that if I am an SA wanting to run a
DBMS server, I will want to run a kernel supplied by a vendor, not an
arbitrary kernel released by a developer, even one as respected as
Alan Cox.
Like, say, Red Hat:
$ ls -l
On Sat, Jun 14, 2003 at 08:32:40PM +0100, Matthew Kirkwood wrote:
On Sat, 14 Jun 2003, Andrew Dunstan wrote:
The trouble with this advice is that if I am an SA wanting to run a
DBMS server, I will want to run a kernel supplied by a vendor, not an
arbitrary kernel released by a developer,
On Sat, 14 Jun 2003, Kurt Roeckx wrote:
$ ls -l /proc/sys/vm/overcommit_memory
-rw-r--r--1 root root0 Jun 14 18:58
/proc/sys/vm/overcommit_memory
$ uname -a
Linux stinky.hoopy.net 2.4.20-20.1.1995.2.2.nptl #1 Fri May 23 12:18:31 EDT 2003
i686 i686 i386 GNU/Linux
Yes, but it's only a binary flag. Non-zero says cheerfully overcommit and
0 says try not to overcommit but there isn't a value that says make sure
not to overcommit.
Have a look in mm/mmap.c in the plain 2.4.21 sources for evidence. There's
nothing like the Alan Cox patch.
IOW, simply the
This occurred to me yesterday as I was designing a little Db.
Has anyone thought about support for a simple enumeration type creation
mechanism? I know I could do it with CREATE TYPE and input/output functions,
but that does seem like a lot of work for a smallish thing.
As it is, I settled on a
Andrew Dunstan [EMAIL PROTECTED] writes:
I *know* the latest RH kernel docs *say* they have paranoid mode that
supposedly guarantees against OOM - it was me that pointed that out
originally :-). I just checked on the latest sources (today it's RH8, kernel
2.4.20-18.8) to be doubly sure, and
Andrew Dunstan [EMAIL PROTECTED] writes:
I *know* the latest RH kernel docs *say* they have paranoid mode that
supposedly guarantees against OOM - it was me that pointed that out
originally :-). I just checked on the latest sources (today it's RH8, kernel
2.4.20-18.8) to be doubly sure, and
I know he does - *but* I think it has probably been wiped out by accident
somewhere along the line (like when they went to 2.4.20?)
Here's what's in RH sources - tell me after you look that I am looking in
the wrong place. (Or did RH get cute and decide to do this only for the AS
product?)
- Original Message -
From: Darko Prenosil [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 13, 2003 5:43 PM
Subject: Fw: [HACKERS] Compiling Win32
- Original Message -
From: Darko Prenosil [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]; Paul Ramsey
[EMAIL
On Saturday 14 June 2003 16:38, Andrew Dunstan wrote:
IOW, simply the presence of /proc/sys/vm/overcommit_memory with a value set
to 0 doesn't guarantee you won't get an OOM kill, AFAICS.
Right. You need the value to be 2 or 3. Which means you need Alan's patch to
do that.
I *know* the
27 matches
Mail list logo
