[HACKERS] Threads in PostgreSQL

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

Re: [HACKERS] Threads in PostgreSQL

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:

Re: [HACKERS] Threads in PostgreSQL

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

Re: [HACKERS] Threads in PostgreSQL

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

Re: [HACKERS] threads stuff/UnixWare

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 has thread flags

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] threads stuff/UnixWare

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 settings

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] threads stuff/UnixWare

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 to pass

Re: [HACKERS] threads stuff/UnixWare

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

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] threads stuff/UnixWare

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. If

Re: [HACKERS] threads stuff/UnixWare

--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. The

Re: [HACKERS] threads stuff/UnixWare

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 stuff to be threads

Re: [HACKERS] threads stuff/UnixWare

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 that does

[HACKERS] threads stuff/UnixWare

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,

Re: [HACKERS] threads stuff/UnixWare

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 REALLY

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] threads stuff/UnixWare

--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 thread

Re: [HACKERS] threads stuff/UnixWare

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

Re: [HACKERS] threads stuff/UnixWare

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 in file

Re: [HACKERS] threads stuff/UnixWare

--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,

Re: [HACKERS] threads stuff/UnixWare

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

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] threads stuff/UnixWare

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 them look via

Re: [HACKERS] threads stuff/UnixWare

--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 to have PG

Re: [HACKERS] threads stuff/UnixWare

--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 Wednesday, May 12, 2004

Re: [HACKERS] threads stuff/UnixWare

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] wrote: On Wed, 12 May

Re: [HACKERS] threads stuff/UnixWare

--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, which was

Re: [HACKERS] threads stuff/UnixWare

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 simpler of a

Re: [HACKERS] threads stuff/UnixWare

--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 linked

Re: [HACKERS] threads stuff/UnixWare

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 :-(.

Re: [HACKERS] threads stuff/UnixWare

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 forces ALL libpq using

Re: [HACKERS] threads stuff/UnixWare

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 that any

Re: [HACKERS] threads stuff/UnixWare

--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 a

Re: [HACKERS] threads stuff/UnixWare

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

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] threads stuff/UnixWare

--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:39:54

Re: [HACKERS] threads stuff/UnixWare

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 settle for saying that

Re: [HACKERS] threads stuff/UnixWare

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 was

Re: [HACKERS] threads stuff/UnixWare

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 was back

Re: [HACKERS] threads stuff/UnixWare

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 is heading down

Re: [HACKERS] threads stuff/UnixWare

--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, then

Re: [HACKERS] threads stuff/UnixWare

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 think the

Re: [HACKERS] threads stuff/UnixWare

--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 you

Re: [HACKERS] threads stuff/UnixWare

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

Re: [HACKERS] threads stuff/UnixWare

--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

Re: [HACKERS] Threads vs Processes

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 in

Re: [pgsql-hackers-win32] [HACKERS] Threads vs Processes

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 correct.

Re: [HACKERS] Threads vs Processes

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 it

Re: [pgsql-hackers-win32] [HACKERS] Threads vs Processes

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 an address

Re: [HACKERS] Threads vs Processes

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

Re: [HACKERS] Threads vs Processes

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 is lack

Re: [pgsql-hackers-win32] [HACKERS] Threads vs Processes

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 expression

Re: [HACKERS] Threads vs Processes

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 there's no

Re: [HACKERS] Threads vs Processes

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 TLS.

Re: [HACKERS] Threads vs Processes

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 mentioned, is to

Re: [HACKERS] Threads vs Processes

-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 Momjian [EMAIL PROTECTED] writes: One

Re: [HACKERS] Threads vs Processes

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 values

[HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for windows)

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 than

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 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 promise to

Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for window

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

Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for window s)

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-thread

Re: [HACKERS] Threads vs Processes

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

Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL

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

Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for windows)

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 a terrible hack job, so

Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for

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 later

Re: [HACKERS] Threads vs Processes

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 it

Re: [HACKERS] Threads vs Processes

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

Re: [HACKERS] Threads vs Processes

] [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

Re: [HACKERS] Threads vs Processes

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: [HACKERS] Threads vs Processes

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 assumed

Re: [HACKERS] Threads vs Processes

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

Re: [HACKERS] Threads vs Processes

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. Myron Scott

Re: [HACKERS] threads/UnixWare

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:

Re: [HACKERS] threads/UnixWare

--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 Specification

Re: [HACKERS] threads/UnixWare

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

Re: [HACKERS] threads/UnixWare

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 the

Re: [HACKERS] threads/UnixWare

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:

Re: [HACKERS] threads/UnixWare

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

Re: [HACKERS] threads/UnixWare

--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,

[HACKERS] threads/UnixWare

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

[HACKERS] Threads considerations on UnixWare 7.1.3

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,

Re: [HACKERS] Threads

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

Re: [HACKERS] Threads

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

Re: [HACKERS] Threads

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 thread

Re: [HACKERS] Threads

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. A

Re: [HACKERS] Threads

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

Re: [HACKERS] Threads

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 implementation.

Re: [HACKERS] Threads

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 that AIO

Re: [HACKERS] Threads

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. You

Re: [HACKERS] Threads

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 worry

Re: [HACKERS] Threads

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 when

Re: [HACKERS] Threads

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 if

Re: [HACKERS] Threads

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

Re: [HACKERS] Threads

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 folds.

Re: [HACKERS] Threads

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..;-) Anyway you

Re: [HACKERS] Threads

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. Those who

Re: [HACKERS] Threads

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 sure I would trust the consistency and state of the others. Or

Re: [HACKERS] Threads

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 sure I

  1   2   >