On Fri, Jan 13, 2012 at 3:14 PM, Frederico <zepfred@gmail.com> wrote:
> Hi folks.
>
> Is there any restriction in create and start threads inside Postgres?
>
> I'm trying to develop a multithread planner, and some times is raised a exception of access memory.
>
> I'm debugging the code to see if is a bug in the planner, but until now, I still not found. I tried to use the same
memorycontext of root process and create a new context to each new thread, but doesn't worked.
>
>
> Any tips?
Yes, don't try to use threads.
<http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F>
... threads are not currently used instead of multiple processes for
backends because:
Historically, threads were poorly supported and buggy. An error in one backend can corrupt other backends if
they're
threads within a single process Speed improvements using threads are small compared to the
remaining backend startup time. The backend code would be more complex. Terminating backend processes allows the OS
tocleanly and quickly
free all resources, protecting against memory and file descriptor
leaks and making backend shutdown cheaper and faster Debugging threaded programs is much harder than debugging
worker
processes, and core dumps are much less useful Sharing of read-only executable mappings and the use of
shared_buffers means processes, like threads, are very memory
efficient Regular creation and destruction of processes helps protect
against memory fragmentation, which can be hard to manage in
long-running processes
There's a pretty large burden of reasons *not* to use threads, and
while some of them have diminished in importance, most have not.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
