Re: Patch for reserved connections for replication users
От | Robert Haas |
---|---|
Тема | Re: Patch for reserved connections for replication users |
Дата | |
Msg-id | CA+TgmoaTotWTVSVWR4BTjZ74n=PVjwtUGbms8ihxRBPDX=9b0Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch for reserved connections for replication users (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Patch for reserved connections for replication users
|
Список | pgsql-hackers |
On Tue, Oct 15, 2013 at 10:34 AM, Andres Freund <andres@2ndquadrant.com> wrote: >> But I also agree that making max_wal_senders act as both a minimum and >> a maximum is no good. +1 to everything Josh Berkus said. > > Josh said we should treat replication connections in a separate "pool" > from normal database connections, right? So you withdraw your earlier > objection to that? I don't think that's what he said. Here's what I was referring to: $ Changing max_wal_senders requires a restart. As such, we currently $ advise users to set the setting generously: "as many replication $ connections as you think you'll ever need, plus two". If $ max_wal_senders is a reservation which could cause the user to run out $ of other connections sooner than expected, then the user is faced with a $ new "hard to set" parameter: they don't want to set it too high *or* too $ low. $ $ This would result in a lot of user frustration as they try to get thier $ connection configuration right and have to restart the server multiple $ times. I find few new features worth making it *harder* to configure $ PostgreSQL, and reserved replication connections certainly don't qualify. $ $ If it's worth having reserved replication connections (and I can see $ some reasons to want it), then we need a new GUC for this: $ "reserved_walsender_connections" -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: