Hi,
PostgreSQL is not using threads but it is possible to spawn thread in
your PostgreSQL extensions.
For example, I have used pool of threads in my IMCS extension.
But you need to build your extension with -pthread:
CUSTOM_COPT = -pthread
Also, please take in account that many PostgreSQL fu
On 12/21/15 01:24, Atri Sharma wrote:
> On Mon, Dec 21, 2015, sri harsha wrote:
>
>> I am using threads in my
>> foreign data wrapper and i get the following error when i use the threads .
>>
>> *ERROR: stack depth limit exceeded*
>> *HINT: Increase the configuration parameter "max_stack_depth"
On Mon, Dec 21, 2015 at 11:51 AM, sri harsha
wrote:
> Hi,
>
>Is it possible to use threads in Postgresql ?? I am using threads in my
> foreign data wrapper and i get the following error when i use the threads .
>
> *ERROR: stack depth limit exceeded*
> *HINT: Increase the configuration para
Hi,
Is it possible to use threads in Postgresql ?? I am using threads in my
foreign data wrapper and i get the following error when i use the threads .
*ERROR: stack depth limit exceeded*
*HINT: Increase the configuration parameter "max_stack_depth" (currently
2048kB), after ensuring the pla
Larry Rosenman wrote:
> > Really? You are configuring with --enable-thread-safety? I just
> > updated your template in CVS, and it is attached. However, any old CVS
> > should work fine.
> Nope, initdb is where we still die:
>
OH! I remember now. What we have to do for this platform only is
--On Thursday, May 13, 2004 11:44:59 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Basically, as things set right now in CVS, Unixware is ready to go
>
Larry Rosenman wrote:
-- Start of PGP signed section.
>
>
> --On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
>
> > Basically, as things set right now in CVS, Unixware is ready to go
> > because it thread for everything. We don't have per-template thread
--On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Basically, as things set right now in CVS, Unixware is ready to go
because it thread for everything. We don't have per-template thread
settings anymore because we test all of it in configure.
Was a change made
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Larry Rosenman wrote:
> >> I agree. the only issue is how to set up our makefiles to only do the
> >> -Kpthread/-pthreads(gcc) flags on the client code, and not do it for
> >> the backend itself.
>
> > I think mixing a pgport that ha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Larry Rosenman wrote:
>> I agree. the only issue is how to set up our makefiles to only do the
>> -Kpthread/-pthreads(gcc) flags on the client code, and not do it for
>> the backend itself.
> I think mixing a pgport that has thread flags with a backend
Larry Rosenman wrote:
-- Start of PGP signed section.
>
>
> --On Thursday, May 13, 2004 09:18:21 -0400 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> >> I did get a note from my SCO contacts that they are looking into how
> >> to make it easier for stuf
--On Thursday, May 13, 2004 09:18:21 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I did get a note from my SCO contacts that they are looking into how
to make it easier for stuff to be threads ready, but I don't expect
that to be ready for 7.5 release.
T
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I did get a note from my SCO contacts that they are looking into how
> to make it easier for stuff to be threads ready, but I don't expect
> that to be ready for 7.5 release.
> The -Kpthread on all libpq using programs is the easiest way FOR NOW.
Hmm.
--On Thursday, May 13, 2004 09:54:02 +0200 Zeugswetter Andreas SB SD
<[EMAIL PROTECTED]> wrote:
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K
pthread.
How about making a libpq.so (without pthread) and a
> I know, this sucks, but, I don't see any other way, other than linking
> *ALL* libpq-using programs (including initdb and friends) with -K
pthread.
How about making a libpq.so (without pthread) and a thread safe
libpq_r.so ?
Andreas
---(end of broadcast)---
--On Wednesday, May 12, 2004 22:26:03 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
Yes, there would still be the overhead, because the functions that
libthread wraps would go through that overhead since libthread does it's
magic at _ini time.
Y'all were concerned with ov
Larry Rosenman wrote:
> Yes, there would still be the overhead, because the functions that
> libthread wraps would go through that overhead since libthread does it's
> magic at _ini time.
>
> Y'all were concerned with overhead in previous discussions.
>
> If you want to link the backend with -K
--On Wednesday, May 12, 2004 21:55:40 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> [ Sorry I have been away from email today. ]
>
> Larry, now that I have put the thread testing into configure, I am
> ready to deal with Unixware. In fact I posted to the list asking yo
Larry Rosenman wrote:
> > [ Sorry I have been away from email today. ]
> >
> > Larry, now that I have put the thread testing into configure, I am ready
> > to deal with Unixware. In fact I posted to the list asking you about it
> > but was too lazy to look up your email address.
> >
> > Anyway, I
--On Wednesday, May 12, 2004 21:08:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Please save us all time searching by providing a URL ...
> I can't find my posts on archives.postgresql.org, but can find it in
> MY archives.
Well,
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> >> Please save us all time searching by providing a URL ...
>
> > I can't find my posts on archives.postgresql.org, but can find it in
> > MY archives.
>
> Well, then we won't be able to find 'em either, so please repost.
>
> > This
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Please save us all time searching by providing a URL ...
> I can't find my posts on archives.postgresql.org, but can find it in
> MY archives.
Well, then we won't be able to find 'em either, so please repost.
> This is heading down the same path I wa
On Wed, 12 May 2004, Larry Rosenman wrote:
> > k, a change that 'sucks', vs linking against -Kpthread ... I'm for the
> > -Kpthread route myself, which still sounds the 'clean' solution ...
> that was rejected back in Jan-Mar.
>
> BUT, I agree it would work.
>
> I tried to submit the patch, and it
On Wed, 12 May 2004, Larry Rosenman wrote:
>
>
> --On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> >> --On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
> >> <[EMAIL PROTECTED]>=20 wrote:
> >>> At this point I'd s
--On Wednesday, May 12, 2004 17:29:30 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
>> --On Wednesday, May 12, 2004 15
--On Wednesday, May 12, 2004 16:22:58 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I was thinking of pq_pthread_* calls, and that function would
> set a static flag for calling either the real pthread_* function
> or a statically named version in libpgport.a that is a single thread
> wrapper.
And how will you avoid having a link-time
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
<[EMAIL PROTECTED]>=20 wrote:
At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane <[EMAIL PROTECTED]>=20
> wrote:
>> At this point I'd settle for saying that --enable-thread-safety on
>> Unixware will generate a library that requires -Kpthread. This is
>> kinda grungy but it seems
On Wed, 12 May 2004, Larry Rosenman wrote:
>
>
> --On Wednesday, May 12, 2004 15:59:19 -0300 "Marc G. Fournier"
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 12 May 2004, Larry Rosenman wrote:
> >
> >> >> > Ummm, shouldn't that be added to the port specific Makefile?
> >> >> See my reply to Tom. It
Larry Rosenman <[EMAIL PROTECTED]> writes:
> This is the whole discussion we had back in January/February about forcing
> -Kpthread for *ALL* libpq using programs, or dynamically determining
> if the image already is linked -Kpthread, or not supporting threads
> at all on UW.
Oh, that business :-(
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
This is the whole discussion we had back in January/February about
forcing -Kpthread for *ALL* libpq using programs, or dynamically
determining if the image already is link
On Wed, 12 May 2004, Larry Rosenman wrote:
> >> > Ummm, shouldn't that be added to the port specific Makefile?
> >> See my reply to Tom. It forces ALL libpq using programs to be
> >> linked with -Kpthread, which was deemed unacceptable.
> >
> > deemed unacceptable by whom? Sounds to me alot simp
--On Wednesday, May 12, 2004 15:59:19 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
>> > Ummm, shouldn't that be added to the port specific Makefile?
>> See my reply to Tom. It forces ALL libpq using programs to be
>> linked with -Kpthread, whi
On Wed, 12 May 2004, Larry Rosenman wrote:
>
>
> --On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 12 May 2004, Larry Rosenman wrote:
> >
> >>
> >>
> >> --On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
> >> <[EMAIL PROTECTED]> w
--On Wednesday, May 12, 2004 15:39:34 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
> On Wed, 12 May 2004, Larry Rosenman wrote:
>
>>
>>
>> --On Wednesda
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
> On Wed, 12 May 2004, Larry Rosenman wrote:
>
>> I'd LIKE to be able
On Wed, 12 May 2004, Larry Rosenman wrote:
>
>
> --On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 12 May 2004, Larry Rosenman wrote:
> >
> >> I'd LIKE to be able to have PG wrappers for those functions, and have
> >> the first invocation of
--On Wednesday, May 12, 2004 13:18:35 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <[EMAIL PROTECTED]>
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined
On Wed, 12 May 2004, Larry Rosenman wrote:
> I'd LIKE to be able to have PG wrappers for those functions, and have
> the first invocation of them look via dlsym() for the real ones, and if
> they are NOT there, use fake functions that assume we are NOT threaded.
Wouldn't it be easier to have a #d
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there,
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <[EMAIL PROTECTED]>
>> In what way does the current thread stuff not work for you?
> In the initdb compile:
> Undefined first referenced
> symbol i
Larry Rosenman <[EMAIL PROTECTED]> writes:
> At the risk of getting my butt kicked again, is there any way we can
> talk about how to deal with threads on UnixWare and the libpq stuff?
In what way does the current thread stuff not work for you?
regards, tom lane
-
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
In what way does the current threa
--On Wednesday, May 12, 2004 12:57:10 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform
On Wed, 12 May 2004, Larry Rosenman wrote:
> At the risk of getting my butt kicked again, is there any way we can
> talk about how to deal with threads on UnixWare and the libpq stuff?
>
> Has any other platform come up with a need to look for the real pthread_*
> calls from libpq?
>
> I would REA
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform come up with a need to look for the real pthread_*
calls from libpq?
I would REALLY like us to support threaded programs in UnixWare, an
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all. The problem we are facing at the
> moment with the Windows port is lack of fork(), which means there's
> no way for separate-subprocess backends to inherit variable
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 26, 2003 9:27 AM
> To: Bruce Momjian
> Cc: Shridhar Daithankar; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Threads vs Processes
>
>
> Bruce Momj
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One solution is for me to continue with this in the Win32 CVS version
> > until I have fork/exec() working on Unix, then test on Win32. I think
> > that could be done in a few weeks, if not less.
>
> > Another solution, already menti
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One solution is for me to continue with this in the Win32 CVS version
> until I have fork/exec() working on Unix, then test on Win32. I think
> that could be done in a few weeks, if not less.
> Another solution, already mentioned, is to use threads and
Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all. The problem we are facing at the
> moment with the Windows port is lack of fork(), which means the
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Surely the addresses can be assumed constant within a thread.
Otherwise we have a problem here too.
Quoting from the MSDN:
The address of a thread local object is not considered constant, and any
express
On Friday 26 September 2003 20:19, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all. The problem we are facing at the
> moment with the Windows port
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> We really don't need threads to replace existing functionality. That
> would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no way for separate-sub
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely the addresses can be assumed constant within a thread.
>> Otherwise we have a problem here too.
> Quoting from the MSDN:
> The address of a thread local object is not considered constant, and any
> expression involving such a
Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
One thing that can be done is to arrange all globals/statics in a
structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I know.
I have following half baked solution. Obviously
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> All TLS variables *must* be static (or implicitly static
>> through extern, i.e. no 'auto' variables)
>I assume you mean static as in not-auto, rather than static as in
>not-global. Otherwise we have a problem here.
Yes, you are cor
> "When the address-of operator is applied to a thread-local variable, it
> is evaluated at run-time and returns the address of the current thread's
> instance of that variable. An address so obtained may be used by any
> thread. When a thread terminates, any pointers to thread-local variables
> Another option would be to create thread local hashtable or other lookup
> structure to which you would register a structure for a particular .c
> file or group of files.
>
> You could then define the structures you need locally without
> affecting other parts of the codebase.
>
>
>
> Myr
Tom Lane wrote:
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
[...]
Surely the addresses can be assumed constant within a thread. Otherwise
we have a problem here too.
[...]
Taking addresses of TLS variables should be considered il
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> All TLS variables *must* be static (or implicitly static
> through extern, i.e. no 'auto' variables)
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
> and their addresses can not be
> a
On Thursday, September 25, 2003, at 10:03 AM, Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
One thing that can be done is to arrange all globals/statics in a
structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I really, re
]
[mailto:[EMAIL PROTECTED] On Behalf Of Merlin Moncure
Sent: Thursday, September 25, 2003 2:49 PM
To: Tom Lane
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bruce
Momjian; Shridhar Daithankar; Claudio Natoli
Subject: Re: [HACKERS] Threads vs Processes
Both Microsoft and windows compilers support thread
Both Microsoft and windows compilers support thread local storage. *If*
you guys go with the threading model and *if* it does not introduce any
serious portability issues with gcc (big ifs, and I'm not familiar with
gcc), than IMO TLS is really the way to go. I don't think any
reorganization of p
helps.
Keith
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 11:57 AM
To: Keith Bottner
Cc: 'Tom Lane'; 'Claudio Natoli'; 'Robert Treat';
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Thre
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> One thing that can be done is to arrange all globals/statics in a
> structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I really, really want to avoid doing anything like the above, because
Keith Bottner wrote:
> Typically variables that you want to be per-thread are stored in what
> Microsoft calls Thread Local Storage (TLS). Variables that you want shared
> you can just treat as globals and statics with the appropriate threading
> synchronization primitives. With Windows 2000 and la
Momjian; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL
for windows)
Claudio Natoli <[EMAIL PROTECTED]> writes:
> FWIW, I've got a threaded version of the WIN32_DEV branch more or less
> "running" (it is
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which varia
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which variables need
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> How are you dealing with the issue of wanting some static variables to
>> be per-thread and others not?
> To be perfectly honest, I'm still trying to familiarize myself with the code
> sufficiently well so that I can tell which variables need to be per
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > FWIW, I've got a threaded version of the WIN32_DEV branch more or less
> > "running" (it is a terrible hack job, so NO, no patches... yet :-), as a
> > proof of concept. Still a work in progress (ok, I've qualified it
enough),
> > but it is showing
Claudio Natoli <[EMAIL PROTECTED]> writes:
> FWIW, I've got a threaded version of the WIN32_DEV branch more or less
> "running" (it is a terrible hack job, so NO, no patches... yet :-), as a
> proof of concept. Still a work in progress (ok, I've qualified it enough),
> but it is showing enough prom
Tom Lane writes:
> BTW, I've been wondering lately if we'd not be better off to look at
> using threading in the Windows port, if it'd help us get around the
> fork/exec data transfer problem. I'm not sure that it would,
> mind you, but if it would give an answer it might be a lot less painful
t
Larry, haven't managed to look at that patch... But stuffed for time
just now - just about to head off for the weekend. I'm hoping to spend
a bit of time on this on Tuesday! So, i'll see how things have
progressed then.
L.
Larry Rosenman writes:
> --On Friday, August 08, 2003 11:53:34 +0100 Lee
--On Friday, August 08, 2003 02:10:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Actually, your getpwuid_r is the old, pre-POSIX format. The attached
email has the configure tests. I was hoping we wouldn't need them, but
it seems we may.
Err, SCO claims SUSv2, the Single Unix Specificatio
Actually, your getpwuid_r is the old, pre-POSIX format. The attached
email has the configure tests. I was hoping we wouldn't need them, but
it seems we may.
---
Larry Rosenman wrote:
> In src/port, we have in threads.c:
>
Of course, I was wrong. In fact, the patch below actually said it was
the pre-POSIX version of getpwuid_r().
---
Bruce Momjian wrote:
>
> Actually, your getpwuid_r is the old, pre-POSIX format. The attached
> email has th
I've not been keeping up with the thread re who has what version of
getpwuid_r... But just to clarify things the "right" version is:
int getpwuid_r(uid_t uid, struct passwd *pwd, char *buffer,
size_t bufsize, struct passwd **result);
documented at:
http://www.opengroup.org/onl
--On Friday, August 08, 2003 11:53:34 +0100 Lee Kindness
<[EMAIL PROTECTED]> wrote:
I've not been keeping up with the thread re who has what version of
getpwuid_r... But just to clarify things the "right" version is:
int getpwuid_r(uid_t uid, struct passwd *pwd, char *buffer,
s
Bruce Momjian writes:
> Actually, your getpwuid_r is the old, pre-POSIX format.
No, his is the right POSIX/SUS variant.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
In src/port, we have in threads.c:
/*
* Wrapper around getpwuid() or getpwuid_r() to mimic POSIX getpwuid_r()
* behaviour, if it is not available.
*/
int
pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer,
size_t buflen, struct passwd ** result)
{
#if defined(USE_THREA
From SCO:
We probably want to be aware of this for a threaded libpq for 7.4.
LER
Forwarded Message
Larry Rosenman wrote:
identity suppressed for NDA reasons
wrote:
So, what I was doing was probably screwing up the syscalls that
libthread wraps?
Or possibly,
Greg Copeland wrote:
On Thu, 2003-01-23 at 09:12, Steve Wampler wrote:
On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
Also remember that in even well developed OS's like FreeBSD, all a
process's threads will execute only on one CPU.
I doubt that
On Thu, 2003-01-23 at 09:12, Steve Wampler wrote:
> On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
> >
> > Also remember that in even well developed OS's like FreeBSD, all a
> > process's threads will execute only on one CPU.
>
> I doubt that - it certainly isn't the case on Linux and Solaris
On Thursday 23 January 2003 08:42 pm, you wrote:
> On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
> > Also remember that in even well developed OS's like FreeBSD, all a
> > process's threads will execute only on one CPU.
>
> I doubt that - it certainly isn't the case on Linux and Solaris.
> A t
On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
>
> Also remember that in even well developed OS's like FreeBSD, all a
> process's threads will execute only on one CPU.
I doubt that - it certainly isn't the case on Linux and Solaris.
A thread may *start* execution on the same CPU as it's pare
On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
> Also remember that in even well developed OS's like FreeBSD, all a
> process's threads will execute only on one CPU.
I would say that that's not terribly well developed. Solaris will split
a single processes' threads over multiple CPUs, and I e
Greg Stark <[EMAIL PROTECTED]> writes:
> You missed the point of his post. If one process in your database does
> something nasty you damn well should worry about the state of and validity of
> the entire database, not just that one backend.
Right. And in fact we do blow away all the processes wh
On Tue, 2003-01-07 at 12:21, Greg Stark wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
>
> > That's the power of using the process model that is currently in use. Should
> > it do something naughty, we bitch and complain politely, throw our hands in
> > the air and exit. We no longer have to w
Greg Copeland <[EMAIL PROTECTED]> writes:
> That's the power of using the process model that is currently in use. Should
> it do something naughty, we bitch and complain politely, throw our hands in
> the air and exit. We no longer have to worry about the state and validity of
> that backend.
Yo
On Tue, 2003-01-07 at 02:00, Shridhar Daithankar wrote:
> On 6 Jan 2003 at 6:48, Greg Copeland wrote:
> > > 1) Get I/O time used fuitfully
> > AIO may address this without the need for integrated threading.
> > Arguably, from the long thread that last appeared on the topic of AIO,
> > some hold th
On 6 Jan 2003 at 6:48, Greg Copeland wrote:
> > 1) Get I/O time used fuitfully
> AIO may address this without the need for integrated threading.
> Arguably, from the long thread that last appeared on the topic of AIO,
> some hold that AIO doesn't even offer anything beyond the current
> implementa
On Mon, 2003-01-06 at 05:36, Shridhar Daithankar wrote:
> On 6 Jan 2003 at 12:22, Ulrich Neumann wrote:
>
> > Hello all,
> > If someone is interested in the code I can send a zip file to everyone
> > who wants.
>
> I suggest you preserver your work. The reason I suggested thread are mainly two
>
On 6 Jan 2003 at 12:22, Ulrich Neumann wrote:
> Hello all,
> If someone is interested in the code I can send a zip file to everyone
> who wants.
I suggest you preserver your work. The reason I suggested thread are mainly two
folds.
1) Get I/O time used fuitfully
2) Use multiple CPU better.
It
Hello all,
it's very interesting to see the discussion of "threads" again.
I've portet PostgreSQL to a "thread-per-connection" model based on
pthreads
and it is functional. Most of the work was finding all the static
globals in the sourcefiles
and swapping them between threads and freeing memory
> "Shridhar" == Shridhar Daithankar <[EMAIL PROTECTED]> writes:
Shridhar> On Saturday 04 January 2003 03:20 am, you wrote:
>> >I am sure, many of you would like to delete this message
>> before reading, > hold on. :-)
>>
>> I'm afraid most posters did not read the message.
On Saturday 04 January 2003 03:20 am, you wrote:
> >I am sure, many of you would like to delete this message before reading,
> > hold on. :-)
>
> I'm afraid most posters did not read the message. Those who replied
>
> "Why bother?" did not address your challenge:
Our challenges may be..;-)
Anyw
On Sat, 2003-01-04 at 06:59, Kaare Rasmussen wrote:
> > Umm. No. User or system level threads, the statement is true. If a
> > thread kills over, the process goes with it. Furthermore, on Win32
>
> Hm. This is a database system. If one of the backend processes dies
> unexpectedly, I'm not sur
1 - 100 of 117 matches
Mail list logo
