Re: [HACKERS] Re: New pg_pwd patch and stuff
От | todd brandys |
---|---|
Тема | Re: [HACKERS] Re: New pg_pwd patch and stuff |
Дата | |
Msg-id | Pine.3.89.9801201137.C1743-0100000@eng3.hep.uiuc.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: New pg_pwd patch and stuff ("Martin J. Laubach" <mjl@emsi.priv.at>) |
Список | 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
В списке pgsql-hackers по дате отправления: