Re: [HACKERS] Streaming replication document improvements

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

In response to

Responses

Browse pgsql-docs by date

  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

Browse pgsql-hackers by date

  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