pgAdmin 4 commit: Allow to send error, and warning on console from the

[Ashesh Vashi]

Allow to send error, and warning on console from the javascript modules.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=8adf005ef8e7b181e303221bc36dc2206e69e8b5

Modified Files
--
web/.eslintrc.js | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

Jenkins build is back to normal : pgadmin4-master-python26 #484

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python33 #357

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python34 #348

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python36 #357

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python27 #358

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python35 #358

[pgAdmin 4 Jenkins]

See 

Re: pgadmin4 l10n issues

[Alexander Lakhin]

Hi Ashesh,

23.10.2017 08:21, Ashesh Vashi wrote:

Hi Dave/Alexander,

On Thu, Oct 19, 2017 at 6:43 PM, Dave Page > wrote:


Akshay, can you review/commit this, and look into why the
remaining strings Alexander notes are not getting translated please?



Did you forget to attach the patch?

No, I didn't. You can find all my attached files here:
https://www.postgresql.org/message-id/5c7914c8-db5f-cb70-a81e-6e9145039935%40gmail.com

Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

pgAdmin 4 commit: Using 'categroy_id' instead of 'cid' in the preferenc

[Ashesh Vashi]

Using 'categroy_id' instead of 'cid' in the preferences Backbone.Model,
as it is used by the Backbone.Collection to get the object by id.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=c53c6d2f485932845d7f345ac0334cf61640c297

Modified Files
--
web/pgadmin/preferences/__init__.py  | 2 +-
web/pgadmin/preferences/static/js/preferences.js | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)

pgAdmin 4 commit: Return the translations, and not empty array from the

[Ashesh Vashi]

Return the translations, and not empty array from the
'translations.js'.

It was regression of the commit-id:
4a91bcde303bd3d5d2bd2e2f20cd7046585eba06

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0a1cf30abb5549e72afb8914e901781b499ab00f
Author: Alexander Lakhin 

Modified Files
--
web/pgadmin/tools/templates/js/translations.js | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

Re: pgadmin4 l10n issues

[Ashesh Vashi]

On Tue, Oct 24, 2017 at 6:08 PM, Alexander Lakhin 
wrote:

> Hi Ashesh,
>
> 23.10.2017 08:21, Ashesh Vashi wrote:
>
> Hi Dave/Alexander,
>
> On Thu, Oct 19, 2017 at 6:43 PM, Dave Page  wrote:
>
>> Akshay, can you review/commit this, and look into why the remaining
>> strings Alexander notes are not getting translated please?
>>
>
>
> Did you forget to attach the patch?
>
> No, I didn't. You can find all my attached files here:
> https://www.postgresql.org/message-id/5c7914c8-db5f-cb70-
> a81e-6e9145039935%40gmail.com
>
I reviewed your patches.
I have committed the first patch.

About the second patch, I understood the issue.
I prefer another approach, instead of proposed by you.

Problem with the approach, you suggested, is: label for
'miscellaneous' Preference object will be always None.
Instead - read the 'raw_value' from the configuration database.

-- Thanks, Ashesh

>
>
> Best regards,
> --
> Alexander Lakhin
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
>


fix-get_locale_v2.patch
Description: Binary data

Build failed in Jenkins: pgadmin4-master-python27 #360

[pgAdmin 4 Jenkins]

See 


--
[...truncated 341.71 KB...]
PackagePutTestCase (Fetch Package Node URL)
TableAddTestCase (Create Range partitioned table with 2 
partitions,
Create List partitioned table with 2 
partitions)
SynonymPutTestCase (Fetch synonym Node URL)
ResourceGroupsPutTestCase (Put resource groups)
TestSSLConnection (Test for SSL connection)
ResourceGroupsDeleteTestCase (Delete resource groups)
SynonymAddTestCase (Default Node URL)
PackageAddTestCase (Fetch Package Node URL)
PackageGetTestCase (Fetch Package Node URL)

PostgreSQL 9.5:

160 tests passed
0 tests failed
15 tests skipped:
SynonymGetTestCase (Fetch synonym Node URL)
PackageDeleteTestCase (Fetch Package Node URL)
TableUpdateTestCase (Detach partition from existing list 
partitioned table,
Create partitions of existing range 
partitioned table,
Detach partition from existing range 
partitioned table,
Attach partition to existing range 
partitioned table,
Attach partition to existing list 
partitioned table,
Create partitions of existing list 
partitioned table)
ResourceGroupsGetTestCase (Get resource groups)
SynonymDeleteTestCase (Fetch synonym Node URL)
ResourceGroupsAddTestCase (Add resource groups)
PackagePutTestCase (Fetch Package Node URL)
TableAddTestCase (Create Range partitioned table with 2 
partitions,
Create List partitioned table with 2 
partitions)
SynonymPutTestCase (Fetch synonym Node URL)
ResourceGroupsPutTestCase (Put resource groups)
TestSSLConnection (Test for SSL connection)
ResourceGroupsDeleteTestCase (Delete resource groups)
SynonymAddTestCase (Default Node URL)
PackageAddTestCase (Fetch Package Node URL)
PackageGetTestCase (Fetch Package Node URL)

PostgreSQL 9.4:

160 tests passed
0 tests failed
15 tests skipped:
SynonymGetTestCase (Fetch synonym Node URL)
PackageDeleteTestCase (Fetch Package Node URL)
TableUpdateTestCase (Detach partition from existing list 
partitioned table,
Create partitions of existing range 
partitioned table,
Detach partition from existing range 
partitioned table,
Attach partition to existing range 
partitioned table,
Attach partition to existing list 
partitioned table,
Create partitions of existing list 
partitioned table)
ResourceGroupsGetTestCase (Get resource groups)
SynonymDeleteTestCase (Fetch synonym Node URL)
ResourceGroupsAddTestCase (Add resource groups)
PackagePutTestCase (Fetch Package Node URL)
TableAddTestCase (Create Range partitioned table with 2 
partitions,
Create List partitioned table with 2 
partitions)
SynonymPutTestCase (Fetch synonym Node URL)
ResourceGroupsPutTestCase (Put resource groups)
TestSSLConnection (Test for SSL connection)
ResourceGroupsDeleteTestCase (Delete resource groups)
SynonymAddTestCase (Default Node URL)
PackageAddTestCase (Fetch Package Node URL)
PackageGetTestCase (Fetch Package Node URL)

PostgreSQL 9.3:

160 tests passed
0 tests failed
15 tests skipped:
SynonymGetTestCase (Fetch synonym Node URL)
PackageDeleteTestCase (Fetch Package Node URL)
TableUpdateTestCase (Detach partition from existing list 
partitioned table,
Create partitions of existing range 
partitioned table,
Detach partition from existing range 
partitioned table,
Attach partition to existing range 
partitioned table,
Attach partition to existing list 
partitioned table,
Create partitions of existing list 
partitioned table)
ResourceGroupsGetTestCase (Get resource groups)
SynonymDeleteTestCase (Fetch synonym

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

[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.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

 


 
 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

 --
 Robert Emery
 Infrastructure Director

 E: robertem...@codeweavers.net | T: 01785 711633 | W:
 www.codeweavers.net

>>>


-- 
Robert Emery
Infrastructure Director

E: robertem...@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net

-- 

Robert Emery
Infrastructure Director

E: robertem...@codeweavers.net | T: 01785
711633 | W: www.codeweavers.net

-- 
 


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

 



*What are Codeweavers doing to gear up for

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

[Ashesh Vashi]

On Tue, Oct 24, 2017 at 8:21 PM, Robert Emery 
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/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.
>
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.

-- 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.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
>
> 
>
>
> 
> 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
>
> --
> Robert Emery
> Infrastructure Director
>
> E: robertem...@codeweavers.net | T: 01785 711633 | W:
> www.codeweavers.net
>

>
>
> --
> Robert Emery
> Infrastructure Director
>
> E: robertem...@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net
>
> 
>
>
> 
> Codeweavers
> October
>  Newsletter
> 
> *l  *Auto Trader extends partnership with

pgAgent commit: When multiple instances of pgAgent are running on the s

[Ashesh Vashi]

When multiple instances of pgAgent are running on the same schema, only
one of the instance can pick up the job to run. Hence - rest of the
instances will never run the job. Hence - the job-thread does not
release the job object.

And, end up leaking the memory.

Releasing the job object from the destructor of the job-thread will
avoid such memory-leak.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgagent.git;a=commitdiff;h=adc49f0a66eae645420f86acd383a75918771bf2
Author: Rob Emery 

Modified Files
--
job.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Re: pgadmin4 l10n issues

[Alexander Lakhin]

24.10.2017 17:17, Ashesh Vashi wrote:
On Tue, Oct 24, 2017 at 6:08 PM, Alexander Lakhin > wrote:


Hi Ashesh,

23.10.2017 08:21, Ashesh Vashi wrote:

Hi Dave/Alexander,

On Thu, Oct 19, 2017 at 6:43 PM, Dave Page mailto:dp...@pgadmin.org>> wrote:

Akshay, can you review/commit this, and look into why the
remaining strings Alexander notes are not getting translated
please?



Did you forget to attach the patch?

No, I didn't. You can find all my attached files here:

https://www.postgresql.org/message-id/5c7914c8-db5f-cb70-a81e-6e9145039935%40gmail.com



I reviewed your patches.
I have committed the first patch.

About the second patch, I understood the issue.
I prefer another approach, instead of proposed by you.
Yes, your approach is better (I tried to minimize the fix and didn't 
notice the label change).

But with the patch applied I get the following error:

File 
"/data/sources/pgadmin4/lib/python2.7/site-packages/pgadmin4/pgadmin/__init__.py", 
line 246, in get_locale

'miscellaneous', 'user_language'
File 
"/data/sources/pgadmin4/lib/python2.7/site-packages/pgadmin4/pgadmin/utils/preferences.py", 
line 502, in raw_value

).filter_by(uid=current_user.id).first()
File 
"/data/sources/pgadmin4/lib/python2.7/site-packages/werkzeug/local.py", 
line 338, in __getattr__

return getattr(self._get_current_object(), name)

AttributeError: 'AnonymousUser' object has no attribute 'id'


Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

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

[Ashesh Vashi]

On Tue, Oct 24, 2017 at 8:30 PM, Ashesh Vashi  wrote:

> On Tue, Oct 24, 2017 at 8:21 PM, Robert Emery  > 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/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.
>>
> 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.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.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
>>
>> 
>>
>>
>> 
>> 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
>>
>> --
>> Robert Emery
>> Infrastructure Director
>>
>> E: robertem...@codeweavers.net | T: 01785 711633 | W:
>>>

Re: pgadmin4 l10n issues

[Ashesh Vashi]

On Tue, Oct 24, 2017 at 8:35 PM, Alexander Lakhin 
wrote:

> 24.10.2017 17:17, Ashesh Vashi wrote:
>
> On Tue, Oct 24, 2017 at 6:08 PM, Alexander Lakhin 
> wrote:
>
>> Hi Ashesh,
>>
>> 23.10.2017 08:21, Ashesh Vashi wrote:
>>
>> Hi Dave/Alexander,
>>
>> On Thu, Oct 19, 2017 at 6:43 PM, Dave Page  wrote:
>>
>>> Akshay, can you review/commit this, and look into why the remaining
>>> strings Alexander notes are not getting translated please?
>>>
>>
>>
>> Did you forget to attach the patch?
>>
>> No, I didn't. You can find all my attached files here:
>> https://www.postgresql.org/message-id/5c7914c8-db5f-cb70-a81
>> e-6e9145039935%40gmail.com
>>
> I reviewed your patches.
> I have committed the first patch.
>
> About the second patch, I understood the issue.
> I prefer another approach, instead of proposed by you.
>
> Yes, your approach is better (I tried to minimize the fix and didn't
> notice the label change).
> But with the patch applied I get the following error:
>
> File 
> "/data/sources/pgadmin4/lib/python2.7/site-packages/pgadmin4/pgadmin/__init__.py",
> line 246, in get_locale
> 'miscellaneous', 'user_language'
> File "/data/sources/pgadmin4/lib/python2.7/site-packages/
> pgadmin4/pgadmin/utils/preferences.py", line 502, in raw_value
> ).filter_by(uid=current_user.id).first()
> File "/data/sources/pgadmin4/lib/python2.7/site-packages/werkzeug/local.py",
> line 338, in __getattr__
> return getattr(self._get_current_object(), name)
>
> AttributeError: 'AnonymousUser' object has no attribute 'id'
>
Looks like - I missed to logout, and test.

Please find the updated patch.

-- Thanks, Ashesh

>
>
>
> Best regards,
> --
> Alexander Lakhin
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
>


fix-get_locale_v3.patch
Description: Binary data

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

[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.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.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
>>>
>>> 
>>>
>>>
>>> 
>>> Codeweavers
>>> October
>>>  Newsletter
>>> 
>>> *l  *Auto Trader extends partnership with Codeweavers
>>> 
>>>
>>>
>>> 
>>>
>>> *What are Codeweavers doing to gear up for GDPR?
>>> *
>>>
>>>
>>>
>>> *Phon

Re: pgadmin4 l10n issues

[Alexander Lakhin]

24.10.2017 18:11, Ashesh Vashi wrote:

Looks like - I missed to logout, and test.

Please find the updated patch.

Now the error is gone but I get no right locale.
The issue is with Desktop mode (see "if config.SERVER_MODE is False:" in 
web/pgadmin/__init__.py).




-- Thanks, Ashesh




Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

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

[Ashesh Vashi]

On Tue, Oct 24, 2017 at 8:59 PM, Rob Emery  wrote:

> Awesome thanks.
>
> What's the release schedule like for pgagent?
>
I have no idea.
That can be answered by Dave only.

Dave?

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company



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



>
> 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.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.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

 


 
 Codeweavers
 October
  Newsletter