Re: Patch for reserved connections for replication users - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Patch for reserved connections for replication users
Date
Msg-id CAA4eK1KRM2giV+zNfj2pvA+q4nTerGoYb87yiD8Hij0Fj1wNzA@mail.gmail.com
Whole thread Raw
In response to Re: Patch for reserved connections for replication users  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Patch for reserved connections for replication users  (Gibheer <gibheer@zero-knowledge.org>)
List pgsql-hackers
On Thu, Oct 17, 2013 at 8:57 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Wed, Oct 16, 2013 at 4:30 AM, Gibheer <gibheer@zero-knowledge.org> wrote:
>> On Mon, 14 Oct 2013 11:52:57 +0530
>> Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>>> On Sun, Oct 13, 2013 at 2:08 PM, Gibheer <gibheer@zero-knowledge.org>
>>> wrote:
>>> > On Sun, 13 Oct 2013 11:38:17 +0530
>>> > Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> >
>>> >> On Thu, Oct 10, 2013 at 3:17 AM, Gibheer
>>> >> <gibheer@zero-knowledge.org> wrote:
>>> >> > On Mon, 7 Oct 2013 11:39:55 +0530
>>> >> > Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> >> >> Robert Haas wrote:
>>> >> >> On Mon, Aug 5, 2013 at 2:04 AM, Andres Freund
>>> >> >> <andres(at)2ndquadrant(dot)com> wrote:
>> I would be glad, if you could also test the patch again, as I'm nearly
>> code blind after testing it for 4 hours.
>> I had the problem, that I could not attach as many replication
>> connections as I wanted, as they were denied as normal connections. I
>> think I got it fixed, but I'm not 100% sure at the moment.
>> After some sleep, I will read the code again and test it again, to make
>> sure, it really does what it is supposed to do.
>
> You have forgotten to attach the patch. However, now it is important
> to first get the consensus on approach to do this feature, currently
> there are 3 approaches:
> 1. Have replication_reserved_connections as a separate parameter to
> reserve connections for replication
> 2. Consider max_wal_sender to reserve connections for replication
> 3. Treat replication connections as a pool outside max_connections
>
> Apart from above approaches, we need to think how user can view the
> usage of connections, as pg_stat_activity doesn't show replication
> connections, so its difficult for user to see how the connections are
> used.
>
> I am really not sure what is best way to goahead from here, but I
> think it might be helpful if we can study some use cases or how other
> databases solve this problem.

Today I spent some time seeing how other databases (in particular
MySQL) achieve it. There seems to be no separate way to configure
replication connections, rather if user faced with
too_many_connections
(https://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html),
they allow one spare connection (super user connection) to check what
all connections are doing, it seems all connections can be viewed
through one common command Show ProcessList
(https://dev.mysql.com/doc/refman/5.5/en/show-processlist.html).

By above, I don't mean that we should only do what other databases
have done, rather it is towards trying to find a way which can be
useful for users of Postgresql.

Your views/thoughts?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Compression of full-page-writes
Next
From: Soroosh Sardari
Date:
Subject: RelFileNode to Relation