Re: [HACKERS] [DOCS] Streaming replication document improvements
On Tue, Apr 20, 2010 at 7:53 PM, Tom Lane wrote: > 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) && >> ReservedBackends > 0 && >> !HaveNFreeProcs(ReservedBackends)) > > As of the patch I just committed, that code is not reached anymore by a > walsender process. However, it shouldn't be hard to put a similar test > into the walsender code path. Thanks for the heads up. It doesn't look hard to put a similar test in the walsender code path, but is there any reason to duplicate the code? Seems like we might be able to just put this test (with the necessary modification) right before this comment: /* * If walsender, we're done here --- we don't want to connect to any * particular database. */ In fact, in some ways, it seems better to put it up there. If the database is really being flooded with connection attempts, we want to ephemerally consume a backend slot for as little time as possible... ...Robert -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [HACKERS] [DOCS] Streaming replication document improvements
Robert Haas writes: > Thanks for the heads up. It doesn't look hard to put a similar test > in the walsender code path, but is there any reason to duplicate the > code? Seems like we might be able to just put this test (with the > necessary modification) right before this comment: Hm, actually I think you're right: we could move both of those connection-rejecting tests up to before the walsender exit. The only extra state we need is ReservedBackends, which should be valid at that point (in particular, it can't be affected by any process-local GUC settings). +1 for just moving the test. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [HACKERS] [DOCS] Streaming replication document improvements
On Wed, Apr 21, 2010 at 12:20 PM, Tom Lane wrote: > Robert Haas writes: >> Thanks for the heads up. It doesn't look hard to put a similar test >> in the walsender code path, but is there any reason to duplicate the >> code? Seems like we might be able to just put this test (with the >> necessary modification) right before this comment: > > Hm, actually I think you're right: we could move both of those > connection-rejecting tests up to before the walsender exit. The I am guessing that by "both of those connection-rejecting tests", you mean the one that can throw "must be superuser to connect during database shutdown" as well as the one we were discussing, which can throw "connection limit exceeded for non-superusers", in which case... > only extra state we need is ReservedBackends, which should be valid > at that point (in particular, it can't be affected by any process-local > GUC settings). > > +1 for just moving the test. ...shouldn't we move the "tests", plural, rather than just the one? It seems right to reject new SR connections during shutdown. ...Robert -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [HACKERS] [DOCS] Streaming replication document improvements
Robert Haas writes: > ...shouldn't we move the "tests", plural, rather than just the one? > It seems right to reject new SR connections during shutdown. Yeah; you'd also need to adjust both of them to consider am_walsender. (IOW, we want to treat SR connections as non-superuser for both tests.) regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
