Home > mailing lists

Re: [pgAgent][Patch] Fixing connection pool leak - Mailing list pgadmin-hackers

From	Rob Emery
Subject	Re: [pgAgent][Patch] Fixing connection pool leak
Date	October 23, 2017 18:10:54
Msg-id	CAPCETptfRcmhFMgNhbYZBhbHrkO+QRDxSNUhuAFtHWMsLZR7tg@mail.gmail.com Whole thread Raw
In response to	Re: [pgAgent][Patch] Fixing connection pool leak (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
List	pgadmin-hackers

Tree view

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 <ashesh.vashi@enterprisedb.com> wrote:

Hi Rob,

How about this?

--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery <re-pgsql@codeweavers.net> wrote:
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: contactus@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: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net