Re: pgAgent: C++ Port - Patch Review - Mailing list pgadmin-hackers

From Dave Page
Subject Re: pgAgent: C++ Port - Patch Review
Date
Msg-id CA+OCxoz37_Uc5Yc_JFydRUzgmLwYkBn6y8xT0SFdSw=VvT8RXw@mail.gmail.com
Whole thread Raw
In response to Re: pgAgent: C++ Port - Patch Review  (Linreg <linreg@gmx.net>)
List pgadmin-hackers



On Sun, Sep 15, 2013 at 6:16 PM, Linreg <linreg@gmx.net> wrote:

Hi Dave,

>

> This change is unrelated to porting to pure C++, and needs to be

> discussed and (if acceptable) implemented as a separate patch. I'm not

> convinced it's an appropriate change at all - I certainly work with

> customer who do not use a connection pooler for various reasons, and

> rely on the pooler in the agent to prevent large numbers of

> connect/disconnect cycles, which amongst other things use resources

> unnecessarily, and can fill up audit logs.

A little addendum:

- connection pooling per Job is not a problem. This changes send i in the next week.

- connection pooling of all jobs has no effect in your code. The function clearconnection released connection-objects before it can be reused after one mainloop cycle. I think. I may be wrong.

so connection pooling per Job should be enough. What do you mean.


Why don't you think it works? The logic at the moment is basically

while (1)
{
  Look for jobs to run

  If jobs are found, run jobs, each in a separate thread

  Else if no jobs were found, purge connections
}

So if you have multiple jobs running in each loop cycle (i.e. the agent is busy), connections are retained. They're only clear if there was no work to do (and then, it'll only affect connections that aren't in use by longer running job threads).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgadmin-hackers by date:

Previous
From: Linreg
Date:
Subject: Re: pgAgent: C++ Port - Patch Review
Next
From: Neel Patel
Date:
Subject: Fix for Slony replication issue in pgAdmin