From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-docs(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Streaming replication document improvements |
Date: | 2010-04-20 13:47:08 |
Message-ID: | h2w3f0b79eb1004200647nc0aa56d8ibb4be9f2f00731f5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Tue, Apr 20, 2010 at 7:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Let's just stop for a second and think about why we have
> superuser_reserved_connections in the first place. As I understand
> it, the point is that we want to make sure that superusers don't get
> locked out of the database, because superuser intervention might be
> necessary to recover from whatever series of unfortunate events has
> caused all of the connection slots to get used up. For example, if
> there are several different applications that connect to the database,
> the superuser might like to log in and see which application has
> requested more than its usual allotment of connections, or the
> superuser might like to log in and terminate those backends which, in
> his judgement, ought to be terminated. In other words, the purpose of
> superuser_reserved_connections is to allow the database to recover
> from a bad state that it has gotten into: specifically, a state where
> all the connection slots have been used up and regular users can't
> connect.
>
> If replication connections can use up superuser_reserved_connections
> slots, then it's very possible that this safety valve will fail
> completely. If the server is being flooded with connection attempts,
> and one of the streaming replication connection dies, then a regular
> backend will immediate grab that slot. When the streaming replication
> slave automatically tries to reconnect, it will now grab one of the
> superuser_reserved_connections slots, putting us one step closer to
> the bad scenario where there's no way for the superuser to log in
> interactively and troubleshoot.
>
> In other words, I don't care whether or not the replication connection
> is or is not technically a superuser connection. What I think is
> important is trying to preserve the ability for a superuser to log in
> interactively and clean up the mess even when the regular supply of
> connections is maxed out.
Yeah, I agree with you, but the difference is only how to achieve.
ISTM that there are three choices:
1. Heikki's proposal
> ReservedBackends = superuser_reserved_connections + max_wal_senders
> MaxBackends = max_connections + autovacuum_max_workers + max_wal_senders + 1
2. My proposal
Remove superuser privilege from replication connection
3. Your proposal
Treat superuser replication connection like non-superuser one
Since 3. is confusing for me, I like 1. or 2.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-04-20 14:01:48 | Re: [HACKERS] Streaming replication document improvements |
Previous Message | Robert Haas | 2010-04-20 13:42:51 | Re: [HACKERS] Streaming replication document improvements |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-04-20 13:57:57 | Re: plpgsql GUC variable: custom or built-in? |
Previous Message | Boszormenyi Zoltan | 2010-04-20 13:46:26 | SpinLockAcquire question |