On Tue, Apr 20, 2010 at 11:01 PM, Robert Haas wrote:
>> 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 fo
Robert Haas writes:
> Current logic says we hit the connection limit if:
> if (!am_superuser &&
> ReservedBackends > 0 &&
> !HaveNFreeProcs(ReservedBackends))
> Couldn't we just change this to:
> if ((!am_superuser || am_walsender) &&
>
Per 8.3 and 8.4 docs:
"In addition to these functions, the SQL OVERLAPS operator is supported:
(start1, end1) OVERLAPS (start2, end2)
(start1, length1) OVERLAPS (start2, length2)
This expression yields true when two time periods (defined by their endpoints)
overlap, false when they do not overla
Tom Lane wrote:
> Robert Haas writes:
>> Fujii Masao wrote:
>>> 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
Robert Haas writes:
> On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao wrote:
>> 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"
On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao 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 + autovacuu
On Tue, Apr 20, 2010 at 7:52 PM, Robert Haas 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 superuse
On Tue, Apr 20, 2010 at 9:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> If replication connections can use up superuser_reserved_connections
>> slots, then it's very possible that this safety valve will fail
>> completely.
>
> Only if replication can use up *all* the superuser_reserved_connecti
Robert Haas writes:
> If replication connections can use up superuser_reserved_connections
> slots, then it's very possible that this safety valve will fail
> completely.
Only if replication can use up *all* the superuser_reserved_connections
slots.
regards, tom lane
--
On Tue, Apr 20, 2010 at 5:47 AM, Fujii Masao wrote:
> On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas wrote:
>> Instead of doing this, could we just change the logic in InitPostgres?
>>
>> Current logic says we hit the connection limit if:
>>
>> if (!am_superuser &&
>> Reserve
On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas wrote:
> Instead of doing this, could we just change the logic in InitPostgres?
>
> Current logic says we hit the connection limit if:
>
> if (!am_superuser &&
> ReservedBackends > 0 &&
> !HaveNFreeProcs(ReservedBac
11 matches
Mail list logo
