Ü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 connections. > 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 match