Marc, not only the global variables are a problem. PostgreSQL doesn't clean up all the memory before a process terminates and you must deal with signals between threads.
I've modified PostgreSQL that it is completely thread based and nearly clean with allocating/deallocating memory and I'm using signals between threads. I've written the code that it's easy to combine the changes with new releases of PostgreSQL but it has some problems that require a decrease of the number of global variables. This is very hard if you don't want to drift away from the main sourcecode of PostgreSQL. Actually I have a table that holds all the globals that needs to be addressed and I can tell you that there are a lot of global variables. However. I've tried to give the changes with the memory freeing back to the main source tree but my feeling was that they don't like it because it doesn't matter on UNIX if you're only process based. The same with several tools like PSQL. After this I wanted to look closer at the global variables. If this may change in the future you would be very happy if you don't have to search for unreleased memory because it is solved. I'm still VERY interested in giving those changes back to the community, but i think that my changes are still not wanted. Another problem I have is that the build tools i'm using are not GNU and the project file is different in this case. The developers from PostgreSQL don't want this too. Currently i'm working on a project file that uses GNU make but i'm not very happy with this because it is dramatically slower compared to the Metrowerks Tools. With Codewarrior I can build PostgreSQL in around 2 Minutes with all libraires and so on and GNU make needs much much longer. But I still hope that I'll find a way how I can handle all this. PostgreSQL itslef is running very good with "only threads" and the database itself is a VERY GOOD product. In the future I'll make some tests to find out information about the performance and how threads affect the performance on Linux. I'm also working on several additions to PostgreSQL for remote realtime Monitoring and configuration, LDAP authentication and more. Ulrich >>> "Marc G. Fournier" <[EMAIL PROTECTED]> 18.10.2002 05:21:59 >>> On Wed, 16 Oct 2002, Anuradha Ratnaweera wrote: > On Wed, Oct 16, 2002 at 01:25:23AM -0400, Bruce Momjian wrote: > > Anuradha Ratnaweera wrote: > > > > > ... what I want to know is whether multithreading is likely to get > > > into in postgresql, say somewhere in 8.x, or even in 9.x? > > > > It may be optional some day, most likely for Win32 at first, but we see > > little value to it on most other platforms; of course, we may be wrong. > > In that case, I wonder if it is worth folking a new project to add > threading support to the backend? Of course, keeping in sync with the > original would be lot of work. Actually, if you go through the archives, there has been talk about what would have to be done to the main source tree towards getting threading included ... as well as a lengthy discussion about the steps involved. the first and foremost issue that needs to be addressed is cleaning up the global variables that are used throughout ... ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---------------------------------- This e-mail is virus scanned Diese e-mail ist virusgeprueft ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
