Re: Limit on number of users in postgresql?

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: "John D(dot) Burger" <john(at)mitre(dot)org>
Cc: "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Limit on number of users in postgresql?
Date: 2007-01-29 19:38:32
Message-ID: 20070129193832.GC14134@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

John D. Burger wrote:
> Tom Lane wrote:
>
> >>What you describe Tom (flat file), sounds a bit strange to me.
> >>Aren't users
> >>stored in a table? (pg_catalog.pg_authid)
> >
> >Yeah, but the postmaster can't read pg_authid, nor any other table,
> >because it's not logically connected to the database. So any change
> >to pg_authid gets copied to a "flat" ASCII-text file for the
> >postmaster.
>
> Why doesn't the postmaster read the db files directly, presumably
> using some of the same code the backends do, or is too hard to bypass
> the shared memory layer?

We used to do that, and we're lucky that it was replaced by the current
plaintext file mechanism, because it was ugly and very limited. And
probably slow too.

> Another thing you folks must have
> considered would be to keep the out-of-memory copies of this kind of
> data in something faster than a flat file - say Berkeley DB. Do
> either of these things make sense?

I don't know a lot about BerkeleyDB, but I'm sure that if plain files
were proven to be a bottleneck we could hack some sort of indexed
storage. Making BDB or something similar a hard requirement is
certainly out of the question. On the other hand, writing such a thing
would probably be more costly than writing a plaintext file ...

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-01-29 19:48:38 Re: Limit on number of users in postgresql?
Previous Message shakahshakah@gmail.com 2007-01-29 19:36:17 VACUUM ANALYZE taking a long time, %I/O and %CPU very low