from:"Rob Emery"

[pgAgent][Patch] Fixing connection pool leak

2017-10-21 Thread Rob Emery

Hi,

Following on from
https://www.postgresql.org/message-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77ZyA%40mail.gmail.com

I think I've identified and fixed the issue, please see the patch attached.

As I understand it when there are multiple pgagent instances and they clash
executing a job (i.e rc != 1 on job.cpp:38), the loser of the conflict's
thread will never be executed (i.e. job.cpp:418 JobThread::Entry), which is
responsible for deleting the job owned by the thread, meaning that the
connection is never returned to the pool. By moving the delete of the job
into the destructor, we can assure that the connection is tidied up in both
cases as the thread is deleted in the error case explicitly in
pgAgent.cpp:185.

The only possibly unintended difference that I can see with doing this is
that the log "Completed job: %s" is now output when before it wasn't,
however I think this new behaviour is actually correct as the job object is
completed at that time.

Thanks,
Rob

-- 
 


Codeweavers 
October
 Newsletter 
  
*l  *Auto Trader extends partnership with Codeweavers 

 



*What are Codeweavers doing to gear up for GDPR? 
*



*Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
*Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 
9705 63 

   
  [image: 
https://plus.google.com/b/105942302039373248738/+CodeweaversNet] 
  [image: 
https://twitter.com/CodeweaversTeam] 
diff --git a/job.cpp b/job.cpp
index 2a94dd7..0b7c146 100644
--- a/job.cpp
+++ b/job.cpp
@@ -412,6 +412,7 @@ JobThread::JobThread(const wxString &jid)
 JobThread::~JobThread()
 {
LogMessage(wxString::Format(_("Destroying job thread for job %s"), 
jobid.c_str()), LOG_DEBUG);
+   delete job;
 }
 
 
@@ -420,7 +421,6 @@ void *JobThread::Entry()
if (runnable)
{
job->Execute();
-   delete job;
}
 
return(NULL);

Re: [pgAgent][Patch] Fixing connection pool leak

2017-10-23 Thread Rob Emery

Hiya,

That seems absolutely fine. I've tested the patch I had over the weekend,
the problem is pretty easy to reproduce with a job that runs every minute
and 4 instances of pgagent.

I'll give this version a test as well, but I'm confident it should be fine.

Thanks,
Rob

On 23 October 2017 at 06:00, Ashesh Vashi 
wrote:

> Hi Rob,
>
> How about this?
>
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
> <http://www.enterprisedb.com>
>
>
> *http://www.linkedin.com/in/asheshvashi*
> <http://www.linkedin.com/in/asheshvashi>
>
> On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery 
> wrote:
>
>> Hi,
>>
>> Following on from https://www.postgresql.org/mes
>> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy
>> A%40mail.gmail.com
>>
>> I think I've identified and fixed the issue, please see the patch
>> attached.
>>
>> As I understand it when there are multiple pgagent instances and they
>> clash executing a job (i.e rc != 1 on job.cpp:38), the loser of the
>> conflict's thread will never be executed (i.e. job.cpp:418
>> JobThread::Entry), which is responsible for deleting the job owned by the
>> thread, meaning that the connection is never returned to the pool. By
>> moving the delete of the job into the destructor, we can assure that the
>> connection is tidied up in both cases as the thread is deleted in the error
>> case explicitly in pgAgent.cpp:185.
>>
>> The only possibly unintended difference that I can see with doing this is
>> that the log "Completed job: %s" is now output when before it wasn't,
>> however I think this new behaviour is actually correct as the job object is
>> completed at that time.
>>
>> Thanks,
>> Rob
>>
>> <https://codeweavers.net>
>>
>>
>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>> Codeweavers
>> October
>>  Newsletter
>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>> *l  *Auto Trader extends partnership with Codeweavers
>> <https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
>>
>>
>> <https://codeweavers.net/automotive-vision-conference-agenda>
>>
>> *What are Codeweavers doing to gear up for GDPR?
>> <https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*
>>
>>
>>
>> *Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
>> *Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18
>> 9AB
>> Registered in England and Wales No. 04092394 | VAT registration no. 974
>> 9705 63
>>
>> --
>> Robert Emery
>> Infrastructure Director
>>
>> E: robertem...@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net
>>
>

-- 
 <https://codeweavers.net>

<http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
Codeweavers 
October
 Newsletter 
<http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>  
*l  *Auto Trader extends partnership with Codeweavers 
<https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
 

<https://codeweavers.net/automotive-vision-conference-agenda>

*What are Codeweavers doing to gear up for GDPR? 
<https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*



*Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
*Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 
9705 63 

<https://www.linkedin.com/company/codeweavers-limited>   
<https://vimeo.com/codeweaversltd>  [image: 
https://plus.google.com/b/105942302039373248738/+CodeweaversNet] 
<https://plus.google.com/b/105942302039373248738/+CodeweaversNet>  [image: 
https://twitter.com/CodeweaversTeam] <https://twitter.com/CodeweaversTeam>

Re: [pgAgent][Patch] Fixing connection pool leak

2017-10-23 Thread Rob Emery

Hiya,

Actually, on reflection (I've not tested yet) but I don't think that'll
actually work. Looking at pgAgent.cpp:119, Create and Run are only executed
if it's Runnable. I've never used WXWidgets before so I'm not sure but I
would guess that Create and Run execute the Entry() method on the new
thread that's build. For that delete to be executed we'd need to move this
outside of the if?

I'll test and confirm this evening

Thanks,
Rob

On 23 October 2017 at 06:00, Ashesh Vashi 
wrote:

> Hi Rob,
>
> How about this?
>
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
> <http://www.enterprisedb.com>
>
>
> *http://www.linkedin.com/in/asheshvashi*
> <http://www.linkedin.com/in/asheshvashi>
>
> On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery 
> wrote:
>
>> Hi,
>>
>> Following on from https://www.postgresql.org/mes
>> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy
>> A%40mail.gmail.com
>>
>> I think I've identified and fixed the issue, please see the patch
>> attached.
>>
>> As I understand it when there are multiple pgagent instances and they
>> clash executing a job (i.e rc != 1 on job.cpp:38), the loser of the
>> conflict's thread will never be executed (i.e. job.cpp:418
>> JobThread::Entry), which is responsible for deleting the job owned by the
>> thread, meaning that the connection is never returned to the pool. By
>> moving the delete of the job into the destructor, we can assure that the
>> connection is tidied up in both cases as the thread is deleted in the error
>> case explicitly in pgAgent.cpp:185.
>>
>> The only possibly unintended difference that I can see with doing this is
>> that the log "Completed job: %s" is now output when before it wasn't,
>> however I think this new behaviour is actually correct as the job object is
>> completed at that time.
>>
>> Thanks,
>> Rob
>>
>> <https://codeweavers.net>
>>
>>
>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>> Codeweavers
>> October
>>  Newsletter
>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>> *l  *Auto Trader extends partnership with Codeweavers
>> <https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
>>
>>
>> <https://codeweavers.net/automotive-vision-conference-agenda>
>>
>> *What are Codeweavers doing to gear up for GDPR?
>> <https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*
>>
>>
>>
>> *Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
>> *Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18
>> 9AB
>> Registered in England and Wales No. 04092394 | VAT registration no. 974
>> 9705 63
>>
>> --
>> Robert Emery
>> Infrastructure Director
>>
>> E: robertem...@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net
>>
>

-- 
 <https://codeweavers.net>

<http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
Codeweavers 
October
 Newsletter 
<http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>  
*l  *Auto Trader extends partnership with Codeweavers 
<https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
 

<https://codeweavers.net/automotive-vision-conference-agenda>

*What are Codeweavers doing to gear up for GDPR? 
<https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*



*Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
*Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 
9705 63 

<https://www.linkedin.com/company/codeweavers-limited>   
<https://vimeo.com/codeweaversltd>  [image: 
https://plus.google.com/b/105942302039373248738/+CodeweaversNet] 
<https://plus.google.com/b/105942302039373248738/+CodeweaversNet>  [image: 
https://twitter.com/CodeweaversTeam] <https://twitter.com/CodeweaversTeam>

Re: [pgAgent][Patch] Fixing connection pool leak

2017-10-23 Thread Rob Emery

Hiya,

I've just confirmed neither of these patches resolve the issue, it appears
in the error case I'm experiencing the JobThread::Entry() never executes.

To clarify I'm talking about the path entering the else in pgAgent.cpp:125
which will save into pga_joblog with jlgstatus = "i"

This path explicitly deletes jt however deleting jt doesn't clean up the
connection, hence why I cascaded the delete in the original patch.

I hope that makes sense

Thanks,
Rob

On 23 October 2017 at 08:18, Neel Patel  wrote:

> Hi Ashesh,
>
> I just added condition before delete the job otherwise it looks good.
> Correct me if I am wrong.
>
> if (job != NULL)
> {
> delete job;
> job = NULL;
> }
>
> I have created two instances of pgagent on database cluster. As of now not
> able to see any leak and keep you updated if found anything.
>
> @Robert - Can you also test at your environment and keep us updated for
> any leak ?
>
> Thanks,
> Neel Patel
>
> On Mon, Oct 23, 2017 at 10:30 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Rob,
>>
>> How about this?
>>
>>
>> --
>>
>> Thanks & Regards,
>>
>> Ashesh Vashi
>> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>> <http://www.enterprisedb.com>
>>
>>
>> *http://www.linkedin.com/in/asheshvashi*
>> <http://www.linkedin.com/in/asheshvashi>
>>
>> On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery 
>> wrote:
>>
>>> Hi,
>>>
>>> Following on from https://www.postgresql.org/mes
>>> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy
>>> A%40mail.gmail.com
>>>
>>> I think I've identified and fixed the issue, please see the patch
>>> attached.
>>>
>>> As I understand it when there are multiple pgagent instances and they
>>> clash executing a job (i.e rc != 1 on job.cpp:38), the loser of the
>>> conflict's thread will never be executed (i.e. job.cpp:418
>>> JobThread::Entry), which is responsible for deleting the job owned by the
>>> thread, meaning that the connection is never returned to the pool. By
>>> moving the delete of the job into the destructor, we can assure that the
>>> connection is tidied up in both cases as the thread is deleted in the error
>>> case explicitly in pgAgent.cpp:185.
>>>
>>> The only possibly unintended difference that I can see with doing this
>>> is that the log "Completed job: %s" is now output when before it wasn't,
>>> however I think this new behaviour is actually correct as the job object is
>>> completed at that time.
>>>
>>> Thanks,
>>> Rob
>>>
>>> <https://codeweavers.net>
>>>
>>>
>>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>>> Codeweavers
>>> October
>>>  Newsletter
>>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>>> *l  *Auto Trader extends partnership with Codeweavers
>>> <https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
>>>
>>>
>>> <https://codeweavers.net/automotive-vision-conference-agenda>
>>>
>>> *What are Codeweavers doing to gear up for GDPR?
>>> <https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*
>>>
>>>
>>>
>>> *Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
>>> *Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18
>>> 9AB
>>> Registered in England and Wales No. 04092394 | VAT registration no. 974
>>> 9705 63
>>>
>>> --
>>> Robert Emery
>>> Infrastructure Director
>>>
>>> E: robertem...@codeweavers.net | T: 01785 711633 | W:
>>> www.codeweavers.net
>>>
>>

-- 
 <https://codeweavers.net>

<http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
Codeweavers 
October
 Newsletter 
<http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>  
*l  *Auto Trader extends partnership with Codeweavers 
<https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
 

<https://codeweavers.net/automotive-vision-conference-agenda>

*What are Codeweavers doing to gear up for GDPR? 
<https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*



*Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
*Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 
9705 63 

<https://www.linkedin.com/company/codeweavers-limited>   
<https://vimeo.com/codeweaversltd>  [image: 
https://plus.google.com/b/105942302039373248738/+CodeweaversNet] 
<https://plus.google.com/b/105942302039373248738/+CodeweaversNet>  [image: 
https://twitter.com/CodeweaversTeam] <https://twitter.com/CodeweaversTeam>

Re: [pgAgent][Patch] Fixing connection pool leak

2017-10-24 Thread Rob Emery

Hello again,

I can't see any other way of solving this problem without either exposing a
method on JobThread to delete the Job owned by the thread which is called
by https://github.com/postgres/pgagent/blob/master/pgAgent.cpp#L139 or
another method that only gives up the connection which is called in the
same place as the delete jt.

Is there a problem with chaining the ~JobThread() and ~Job() together as I
suggested previously? This does solve the leak.

Many Thanks,
Rob

On 23 October 2017 at 20:09, Rob Emery  wrote:

> Hiya,
>
> I've just confirmed neither of these patches resolve the issue, it appears
> in the error case I'm experiencing the JobThread::Entry() never executes.
>
> To clarify I'm talking about the path entering the else in pgAgent.cpp:125
> which will save into pga_joblog with jlgstatus = "i"
>
> This path explicitly deletes jt however deleting jt doesn't clean up the
> connection, hence why I cascaded the delete in the original patch.
>
> I hope that makes sense
>
> Thanks,
> Rob
>
> On 23 October 2017 at 08:18, Neel Patel 
> wrote:
>
>> Hi Ashesh,
>>
>> I just added condition before delete the job otherwise it looks good.
>> Correct me if I am wrong.
>>
>> if (job != NULL)
>> {
>> delete job;
>> job = NULL;
>> }
>>
>> I have created two instances of pgagent on database cluster. As of now
>> not able to see any leak and keep you updated if found anything.
>>
>> @Robert - Can you also test at your environment and keep us updated for
>> any leak ?
>>
>> Thanks,
>> Neel Patel
>>
>> On Mon, Oct 23, 2017 at 10:30 AM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> Hi Rob,
>>>
>>> How about this?
>>>
>>>
>>> --
>>>
>>> Thanks & Regards,
>>>
>>> Ashesh Vashi
>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>>> <http://www.enterprisedb.com>
>>>
>>>
>>> *http://www.linkedin.com/in/asheshvashi*
>>> <http://www.linkedin.com/in/asheshvashi>
>>>
>>> On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Following on from https://www.postgresql.org/mes
>>>> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy
>>>> A%40mail.gmail.com
>>>>
>>>> I think I've identified and fixed the issue, please see the patch
>>>> attached.
>>>>
>>>> As I understand it when there are multiple pgagent instances and they
>>>> clash executing a job (i.e rc != 1 on job.cpp:38), the loser of the
>>>> conflict's thread will never be executed (i.e. job.cpp:418
>>>> JobThread::Entry), which is responsible for deleting the job owned by the
>>>> thread, meaning that the connection is never returned to the pool. By
>>>> moving the delete of the job into the destructor, we can assure that the
>>>> connection is tidied up in both cases as the thread is deleted in the error
>>>> case explicitly in pgAgent.cpp:185.
>>>>
>>>> The only possibly unintended difference that I can see with doing this
>>>> is that the log "Completed job: %s" is now output when before it wasn't,
>>>> however I think this new behaviour is actually correct as the job object is
>>>> completed at that time.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> <https://codeweavers.net>
>>>>
>>>>
>>>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>>>> Codeweavers
>>>> October
>>>>  Newsletter
>>>> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169&id=f556b0bf09>
>>>> *l  *Auto Trader extends partnership with Codeweavers
>>>> <https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites>
>>>>
>>>>
>>>> <https://codeweavers.net/automotive-vision-conference-agenda>
>>>>
>>>> *What are Codeweavers doing to gear up for GDPR?
>>>> <https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>*
>>>>
>>>>
>>>>
>>>> *Phone:* 0800 021 0888  * Email: *contac...@codeweavers.net
>>>> *Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18

Re: [pgAgent][Patch] Fixing connection pool leak

2017-10-24 Thread Rob Emery

Awesome thanks.

What's the release schedule like for pgagent?

Thanks,
Rob



On 24 October 2017 at 16:05, Ashesh Vashi 
wrote:

> On Tue, Oct 24, 2017 at 8:30 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> On Tue, Oct 24, 2017 at 8:21 PM, Robert Emery <
>> robertem...@codeweavers.net> wrote:
>>
>>> Hello again,
>>>
>>> I can't see any other way of solving this problem without either
>>> exposing a method on JobThread to delete the Job owned by the thread which
>>> is called by https://github.com/postgres/pg
>>> agent/blob/master/pgAgent.cpp#L139 or another method that only gives up
>>> the connection which is called in the same place as the delete jt.
>>>
>>> Is there a problem with chaining the ~JobThread() and ~Job() together as
>>> I suggested previously? This does solve the leak.
>>>
>> Nothing wrong in it.
>> My intention was to release the object asap.
>>
>> As per your findings, it won't go in that execution flow in all cases. I
>> will commit your patch.
>>
> Committed your original patch.
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
> <http://www.enterprisedb.com/>
>
>
> *http://www.linkedin.com/in/asheshvashi*
> <http://www.linkedin.com/in/asheshvashi>
>
>>
>> -- Thanks, Ashesh
>>
>>>
>>> Many Thanks,
>>> Rob
>>>
>>> On 23 October 2017 at 20:09, Rob Emery  wrote:
>>>
>>>> Hiya,
>>>>
>>>> I've just confirmed neither of these patches resolve the issue, it
>>>> appears in the error case I'm experiencing the JobThread::Entry() never
>>>> executes.
>>>>
>>>> To clarify I'm talking about the path entering the else in
>>>> pgAgent.cpp:125 which will save into pga_joblog with jlgstatus = "i"
>>>>
>>>> This path explicitly deletes jt however deleting jt doesn't clean up
>>>> the connection, hence why I cascaded the delete in the original patch.
>>>>
>>>> I hope that makes sense
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> On 23 October 2017 at 08:18, Neel Patel 
>>>> wrote:
>>>>
>>>>> Hi Ashesh,
>>>>>
>>>>> I just added condition before delete the job otherwise it looks good.
>>>>> Correct me if I am wrong.
>>>>>
>>>>> if (job != NULL)
>>>>> {
>>>>> delete job;
>>>>> job = NULL;
>>>>> }
>>>>>
>>>>> I have created two instances of pgagent on database cluster. As of now
>>>>> not able to see any leak and keep you updated if found anything.
>>>>>
>>>>> @Robert - Can you also test at your environment and keep us updated
>>>>> for any leak ?
>>>>>
>>>>> Thanks,
>>>>> Neel Patel
>>>>>
>>>>> On Mon, Oct 23, 2017 at 10:30 AM, Ashesh Vashi <
>>>>> ashesh.va...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> How about this?
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Thanks & Regards,
>>>>>>
>>>>>> Ashesh Vashi
>>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>>>>>> <http://www.enterprisedb.com>
>>>>>>
>>>>>>
>>>>>> *http://www.linkedin.com/in/asheshvashi*
>>>>>> <http://www.linkedin.com/in/asheshvashi>
>>>>>>
>>>>>> On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Following on from https://www.postgresql.org/mes
>>>>>>> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy
>>>>>>> A%40mail.gmail.com
>>>>>>>
>>>>>>> I think I've identified and fixed the issue, please see the patch
>>>>>>> attached.
>>>>>>>
>>>>>>> As I understand it when there are multiple pgagent instances and
>>>>>>> they clash executing a job (i.e rc

PGAgent 4.0 error feedback

2018-06-09 Thread Rob Emery

Hi Guys,

I've been testing out PGAgent 4 (build today from master at commit
86ca5c5ed1ad572075ba27e05e4680ebdf5b9feb) to check the connection
handling on error is still fixed with the boost reimplementation
(which it is!)
and noticed a few issues compared to PGAgent 3 around feedback to the
user if the connection string is incorrect.

I've tested with incorrect username and password, user not in the hba,
db doesn't exist, postgresql not running on the host (or incorrect
hostaddr) and 4 seems to always returns the error :
`
ERROR: Couldn't find the function 'pgagent_schema_version' - please
run pgagent_upgrade.sql.
`

whereas 3.4.1 tends to output from the pgconnection itself like:
`
Sat Jun  9 21:32:13 2018 : WARNING: Couldn't create the primary
connection (attempt 1): FATAL:  no pg_hba.conf entry for host
"172.30.0.16", user "pgagent_login_role", database
"pgagent_login_role", SSL on
FATAL:  no pg_hba.conf entry for host "172.30.0.16", user
"pgagent_login_role", database "pgagent_login_role", SSL off
`

which at least points the user towards the actual error!

Not sure if this is known already, but I thought I'd raise it prior to release.

Thanks,
Rob
--

-- 
 


Codeweavers May Newsletter 
  l  Codeweavers April 
Finance Trends 



April’s Dealer Highlights 
 


_
_



*Phone:* 0800 021 0888   Email: contac...@codeweavers.net 

Codeweavers Ltd | Barn 4 | Dunston 
Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 
04092394 | VAT registration no. 974 9705 63

Re: PGAgent 4.0 error feedback

2018-06-11 Thread Rob Emery

Hi Ashesh,

Log-level wise I was using the same command for both versions:

 ./pgagent -f -l 2 -t 1 -r 1 'hostaddr=server user=username
password=password dbname=postgres'

and messing up the connection string in various ways (missing dbname,
incorrect password, incorrect hostaddr)

This was built and tested on  Debian GNU/Linux 9.4 (stretch).

I've attached an example of the differing output when the dbname is missing
from the connectionstring; basically it's the same for all errors.

Many Thanks,
Rob

On 11/06/2018, Ashesh Vashi  wrote:
> Hi Rob,
>
> On Sun, Jun 10, 2018 at 2:26 AM, Rob Emery 
> wrote:
>
>> Hi Guys,
>>
>> I've been testing out PGAgent 4 (build today from master at commit
>> 86ca5c5ed1ad572075ba27e05e4680ebdf5b9feb) to check the connection
>> handling on error is still fixed with the boost reimplementation
>> (which it is!)
>> and noticed a few issues compared to PGAgent 3 around feedback to the
>> user if the connection string is incorrect.
>>
>> I've tested with incorrect username and password, user not in the hba,
>> db doesn't exist, postgresql not running on the host (or incorrect
>> hostaddr) and 4 seems to always returns the error :
>> `
>> ERROR: Couldn't find the function 'pgagent_schema_version' - please
>> run pgagent_upgrade.sql.
>> `
>>
>> whereas 3.4.1 tends to output from the pgconnection itself like:
>> `
>> Sat Jun  9 21:32:13 2018 : WARNING: Couldn't create the primary
>> connection (attempt 1): FATAL:  no pg_hba.conf entry for host
>> "172.30.0.16", user "pgagent_login_role", database
>> "pgagent_login_role", SSL on
>> FATAL:  no pg_hba.conf entry for host "172.30.0.16", user
>> "pgagent_login_role", database "pgagent_login_role", SSL off
>> `
>>
>> which at least points the user towards the actual error!
>>
>> Not sure if this is known already, but I thought I'd raise it prior to
>> release.
>>
> Thanks for sharing the information.
>
> Is it possible for you to share the logs with log level set to debug?
> Also - please share the operating system details?
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
> <http://www.enterprisedb.com/>
>
>
> *http://www.linkedin.com/in/asheshvashi*
> <http://www.linkedin.com/in/asheshvashi>
>
>
>
>>
>> Thanks,
>> Rob
>> --
>>
>> --
>>  <https://codeweavers.net>
>>
>>
>> Codeweavers May Newsletter
>> <https://mailchi.mp/codeweavers/march-edition-336883>  l  Codeweavers
>> April
>> Finance Trends
>> <https://codeweavers.net/company-blog/codeweavers-april-finance-trends>
>>
>>
>> April’s Dealer Highlights
>> <https://codeweavers.net/company-blog/aprils-dealer-highlights>
>> <https://codeweavers.net/company-blog/codeweavers-march-car-finance-trends
>> >
>>
>> _
>> _
>>
>>
>>
>> *Phone:* 0800 021 0888   Email: contac...@codeweavers.net
>> <mailto:contac...@codeweavers.net>
>> Codeweavers Ltd | Barn 4 | Dunston
>> Business Village | Dunston | ST18 9AB
>> Registered in England and Wales No.
>> 04092394 | VAT registration no. 974 9705 63
>>
>>
>>
>>
>> <https://www.linkedin.com/company/codeweavers-limited>
>> <https://vimeo.com/codeweaversltd>
>> <https://plus.google.com/b/105942302039373248738/+CodeweaversNet>
>> <https://twitter.com/CodeweaversTeam>
>>
>>
>>
>

-- 
 <https://codeweavers.net>


Codeweavers May Newsletter 
<https://mailchi.mp/codeweavers/march-edition-336883>  l  Codeweavers April 
Finance Trends 
<https://codeweavers.net/company-blog/codeweavers-april-finance-trends>


April’s Dealer Highlights 
<https://codeweavers.net/company-blog/aprils-dealer-highlights> 
<https://codeweavers.net/company-blog/codeweavers-march-car-finance-trends>

_
_



*Phone:* 0800 021 0888   Email: contac...@codeweavers.net 
<mailto:contac...@codeweavers.net>
Codeweavers Ltd | Barn 4 | Dunston 
Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 
04092394 | VAT registration no. 974 9705 63 



 
<https://www.linkedin.com/company/codeweavers-limited>   
<https://vimeo.com/codeweaversltd>   
<https://plus.google.com/b/105942302039373248738/+CodeweaversNet>   
<https://twitter.com/CodeweaversTeam>

rob@ISIS:~/pgagent-git-build$ ./pgagent -f 'hostaddr=172.30.0.16 
user=pgagent_login_role password=password'
Mon Jun 11 08:17:49 2018 ERROR: Couldn't find the function 
'pgagent_schema_version' - please run pgagent_upgrade.sql.

rob@ISIS:~/pgagent-3.4.1-build$ ./pgagent -f 'hostaddr=172.30.0.16 
user=pgagent_login_role password=password'
Mon Jun 11 08:18:01 2018 : WARNING: Couldn't create the primary connection 
(attempt 1): could not connect to server: Connection refused
Is the server running on host "172.30.0.16" and accepting
TCP/IP connections on port 5432?

Fwd: PGAgent 4.0 error feedback

2018-06-11 Thread Rob Emery

Hello Again,

I've just tested the patch and the output is *much* more verbose with the same
set of flags now, even more so than the old version (see attached).

Thanks,
Rob

On 11/06/2018, Ashesh Vashi  wrote:
> Hi Rob,
>
>
> On Mon, Jun 11, 2018 at 12:50 PM, Rob Emery 
> wrote:
>
>> Hi Ashesh,
>>
>> Log-level wise I was using the same command for both versions:
>>
>>  ./pgagent -f -l 2 -t 1 -r 1 'hostaddr=server user=username
>> password=password dbname=postgres'
>>
>> and messing up the connection string in various ways (missing dbname,
>> incorrect password, incorrect hostaddr)
>>
>> This was built and tested on  Debian GNU/Linux 9.4 (stretch).
>>
> If you're working on the source, would please test the patch sent by me?
>
>>
>> I've attached an example of the differing output when the dbname is
>> missing
>> from the connectionstring; basically it's the same for all errors.
>>
>
> Thanks a lot for the information.
>
> -- Thanks, Ashesh
>
>>
>> Many Thanks,
>> Rob
>>
>> On 11/06/2018, Ashesh Vashi  wrote:
>> > Hi Rob,
>> >
>> > On Sun, Jun 10, 2018 at 2:26 AM, Rob Emery 
>> > wrote:
>> >
>> >> Hi Guys,
>> >>
>> >> I've been testing out PGAgent 4 (build today from master at commit
>> >> 86ca5c5ed1ad572075ba27e05e4680ebdf5b9feb) to check the connection
>> >> handling on error is still fixed with the boost reimplementation
>> >> (which it is!)
>> >> and noticed a few issues compared to PGAgent 3 around feedback to the
>> >> user if the connection string is incorrect.
>> >>
>> >> I've tested with incorrect username and password, user not in the hba,
>> >> db doesn't exist, postgresql not running on the host (or incorrect
>> >> hostaddr) and 4 seems to always returns the error :
>> >> `
>> >> ERROR: Couldn't find the function 'pgagent_schema_version' - please
>> >> run pgagent_upgrade.sql.
>> >> `
>> >>
>> >> whereas 3.4.1 tends to output from the pgconnection itself like:
>> >> `
>> >> Sat Jun  9 21:32:13 2018 : WARNING: Couldn't create the primary
>> >> connection (attempt 1): FATAL:  no pg_hba.conf entry for host
>> >> "172.30.0.16", user "pgagent_login_role", database
>> >> "pgagent_login_role", SSL on
>> >> FATAL:  no pg_hba.conf entry for host "172.30.0.16", user
>> >> "pgagent_login_role", database "pgagent_login_role", SSL off
>> >> `
>> >>
>> >> which at least points the user towards the actual error!
>> >>
>> >> Not sure if this is known already, but I thought I'd raise it prior to
>> >> release.
>> >>
>> > Thanks for sharing the information.
>> >
>> > Is it possible for you to share the logs with log level set to debug?
>> > Also - please share the operating system details?
>> >
>> > --
>> >
>> > Thanks & Regards,
>> >
>> > Ashesh Vashi
>> > EnterpriseDB INDIA: Enterprise PostgreSQL Company
>> > <http://www.enterprisedb.com/>
>> >
>> >
>> > *http://www.linkedin.com/in/asheshvashi*
>> > <http://www.linkedin.com/in/asheshvashi>
>> >
>> >
>> >
>> >>
>> >> Thanks,
>> >> Rob
>> >> --
>> >>
>> >> --
>> >>  <https://codeweavers.net>
>> >>
>> >>
>> >> Codeweavers May Newsletter
>> >> <https://mailchi.mp/codeweavers/march-edition-336883>  l  Codeweavers
>> >> April
>> >> Finance Trends
>> >> <https://codeweavers.net/company-blog/codeweavers-april-finance-trends>
>> >>
>> >>
>> >> April’s Dealer Highlights
>> >> <https://codeweavers.net/company-blog/aprils-dealer-highlights>
>> >> <https://codeweavers.net/company-blog/codeweavers-
>> march-car-finance-trends
>> >> >
>> >>
>> >> _
>> >> _
>> >>
>> >>
>> >>
>> >> *Phone:* 0800 021 0888   Email: contac...@codeweavers.net
>> >> <mailto:contac...@codeweavers.net>
>> >> Codeweavers Ltd | Barn 4 | Dunston
>> >> Business Village | Dunston | ST18 9AB
>> >>

[pgAgent][Patch] Fixing connection pool leak

Re: [pgAgent][Patch] Fixing connection pool leak

Re: [pgAgent][Patch] Fixing connection pool leak

Re: [pgAgent][Patch] Fixing connection pool leak

Re: [pgAgent][Patch] Fixing connection pool leak

Re: [pgAgent][Patch] Fixing connection pool leak

PGAgent 4.0 error feedback

Re: PGAgent 4.0 error feedback

Fwd: PGAgent 4.0 error feedback

9 matches

Site Navigation

Mail list logo

Footer information