Re: [HACKERS] Re: New pg_pwd patch and stuff
todd brandys <brandys@eng3.hep.uiuc.edu>
From: todd brandys <brandys@eng3.hep.uiuc.edu>
To: "Martin J. Laubach" <mjl@emsi.priv.at>
Cc: phil@river-bank.demon.co.uk, scrappy@hub.org, mimo@lodz.pdi.net, hackers@postgreSQL.org
Date: 1998-01-20T18:10:23Z
Lists: pgsql-hackers
On Mon, 19 Jan 1998, Martin J. Laubach wrote: > So, if postmaster can't access the system tables for authentication > purposes, why not have one child forked, connected to the main > postmaster process via some IPC mechanism, whose only purpose > in life it is to answer SQL-queries for postmaster. > > mjl > > I would have to say "footprint". All the code for the backend has been incorporated into the postmaster. The postmaster is nothing more than a backend run with some special command line options. The postgres executable is over 1 MB large and is a static executable. This is quite a bit of (virtual) memory. I realize that memory is cheap these days, but to have all the backend code included in with the postmaster and not have it useable is a waste of resources. To then have a second instance running would take more resources. If we must maintain user authorization in the postmaster, then I believe it would be best to strip this code from the postgres executable to create a postmaster with a smaller footprint. Furthermore, the postmaster should be made capable of performing heapscans, so that it could at least view the data in the system catalog. Then all the data needed for each authentication method (or a single method if we incorporated the best aspects of each method into one super authentication method), could be stored in the system catalog. This information could then be managed by the CREATE/ALTER USER statements, which would alleviate the need to edit flat files for system configuration. Todd A. Brandys brandys@eng3.hep.uiuc.edu