Ühel kenal päeval, E, 2006-07-31 kell 09:52, kirjutas Tom Lane:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Martijn van Oosterhout wrote:
> >> Maybe someone should look into enabling slony to not run as a
> >> superuser?
> > That was my initial reaction to this suggestion. But then I realised 
> > that it might well make sense to have a separate connection-limited 
> > superuser for Slony purposes (or any other special purpose) alongside an 
> > unlimited superuser.
> Actually, the real question in my mind is why Slony can't be trusted
> to use the right number of connections to start with.  If you don't
> trust it that far, what are you doing letting it into your database as
> superuser to start with?

This has probably nothing to do withs slony. One way tos shut out users
from postgresqls backend is to cut all connections in a way that a smart
client sees (maybe by sending keepalives), but backend does not (it
times out after some TCP timeout, which by default is in about
2.5hours). BTW, sometimes this does happen by itself in case of long
enough connections.

In such a case the client will likely establish new connection(s), and
if the whole process happens many times, then the backend runs out of

> As for "connection-limited superuser", if you can't do ALTER USER SET
> on yourself then you aren't a superuser, so any such restriction is
> illusory anyway.

I guess they want protection against accidentally using up all
connections, not to have a way for competing superusers to locking each
other out;

Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to