On Fri, Jan 13, 2012 at 3:14 PM, Frederico <zepf...@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 memory context 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 to cleanly 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?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers