Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Streaming replication document improvements

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(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 14:01:48
Message-ID: h2g603c8f071004200701jff98aca6sfd063608572e463@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackers
On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> 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

This seemed sensible to me when Heikki first described it, but now it
seems overly complex.

> 2. My proposal
>    Remove superuser privilege from replication connection

I'm not sure this really fixes the problem.  If we add a separate
replication privilege, then presumably superusers will automatically
have that privilege, in accord with our usual policy on such things.
So potentially someone could still set up replication using a
superuser account and then they could still get bitten by this
problem.

> 3. Your proposal
>    Treat superuser replication connection like non-superuser one

Well, only for this one very specific purpose.  I would adjust the
docs like this:

Determines the number of connection "slots" that are reserved for
connections by PostgreSQL  superusers. At most max_connections
connections can ever be active simultaneously. Whenever the number of
active concurrent connections is at least max_connections minus
superuser_reserved_connections, new connections will be accepted only
for superusers, and no new replication connections will be accepted.

I think that's pretty simple and clear.  If we want to burn an extra
sentence explaining what this is all about, we could add:

(If replication connections were permitted to use the reserved
connection slots, an installation with max_wal_senders set to a value
greater than or equal to the value set for
superuser_reserved_connections might find that no reserved connections
remained for interactive access to the database.)

> Since 3. is confusing for me, I like 1. or 2.

What do others think?

...Robert

In response to

Responses

pgsql-docs by date

Next:From: Tom LaneDate: 2010-04-20 14:08:37
Subject: Re: [HACKERS] Streaming replication document improvements
Previous:From: Fujii MasaoDate: 2010-04-20 13:47:08
Subject: Re: [HACKERS] Streaming replication document improvements

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-04-20 14:05:09
Subject: Re: Thoughts on pg_hba.conf rejection
Previous:From: Tom LaneDate: 2010-04-20 13:57:57
Subject: Re: plpgsql GUC variable: custom or built-in?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group