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

[pgAdmin 4 Jenkins]

See 


--
[...truncated 1012.21 KB...]
TestUtilityCheckRouteCase (Check utility path route for backup 
utility,
Check utility path route for 
maintenance utility,
Check utility path route for import 
export utility,
Check utility path route for restore 
utility)
RestoreCreateJobTest (When restore object with option - Disbale,
When restore the object with Type of 
objects,
When restore object with option - 
Miscellaneous,
When restore object with option - Do 
not save,
When restore object with option - 
Queries,
When restore object with default 
options,
When restore object with the sections 
options,
When restore object with option - Do 
not save comments,
When restore object with format 
directory)
PgAgentDeleteStepTestCase (Delete pgAgent Step)
PgAgentPutScheduleTestCase (Update schedule with repeat,
Update schedule change exception date 
and time,
Update schedule delete exception,
Update schedule add exception,
Update schedule with start and end time)
BackupJobTest (When backup the object with the default options)
TestSSLConnection (Test for SSL connection)
PgAgentGetTestCase (Get pgAgent job)
PgAgentPutStepTestCase (Update step with kind, description, 
code and error,
Update step with connection type and 
string)
PgAgentDeleteTestCase (Delete pgAgent job)
RestoreJobTest (When restore the object with the default 
options)
PgAgentDeleteScheduleTestCase (Delete pgAgent Schedule)

EDB Postgres AS 9.2:

463 tests passed
0 tests failed
35 tests skipped:
PgAgentAddStepTestCase (Create step for pgAgent job)
PgAgentAddScheduleTestCase (Create schedule with exception in 
pgAgent job)
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)
ViewsDeleteTestCase (Delete materialized view under schema node)
ViewsGetTestCase (Get materialized view under schema node)
PgAgentPutTestCase (Put pgAgent job)
ResourceGroupsGetTestCase (Get resource groups)
TableAddTestCase (Create Hash partitioned table with 2 
partitions,
Create Range partitioned table with 2 
partitions,
Create List partitioned table with 2 
partitions)
ViewsDeleteMultipleTestCase (Delete multiple materialized view 
under schema node)
PgAgentDeleteScheduleTestCase (Delete pgAgent Schedule)
ResourceGroupsDeleteTestCase (Delete multiple resource groups,
Delete resource groups)
PgAgentPutScheduleTestCase (Update schedule with repeat,
Update schedule change exception date 
and time,
Update schedule delete exception,
Update schedule add exception,
Update schedule with start and end time)
ViewsAddTestCase (Add materialized view under schema node)
EventTriggerDeleteTestCase (Fetch Event Trigger Node URL)
MaintenanceJobTest (When maintenance the object with the 
default options)
MaintenanceCreateJobTest (When maintenance the object with the 
CLUSTER,
When maintenance object with VACUUM 
FULL,
When maintenance object with the 
ANALYZE,
When maintenance the object with the 
REINDEX,
   

Re: Async queries pretending to be synchronous

[Dave Page]

Hi

On Mon, Mar 4, 2019 at 5:43 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Mar 1, 2019 at 10:01 PM Dave Page  wrote:
>
>> In investigating #3656 I found the initial problem to be that when
>> running in a container, Gunicorn will kill the worker process if a thread
>> doesn't respond for 30 seconds by default. I fixed that by making the
>> timeout match the application session timeout, but it revealed another
>> issue.
>>
>> Given the function below (from the ticket), if you open the query tool
>> and run:
>>
>> SELECT 1; SELECT fails_after(30);
>>
>> the async query actually blocks for 30 seconds in the cur.execute() call
>> in execute_async() in connection.py (line 968). This causes the entire app
>> to hang (watch the dashboard requests pile up in pending state in the
>> network tab of the browser dev tools).
>>
>> If you run just the second SELECT, it works as expected, as does running
>> something like:
>>
>> SELECT 1; SELECT pg_sleep(30);
>>
>> Anyone have any idea what's going on?
>>
>
> Connection.poll() blocking the call here. ( connection.py -  _wait_timeout
> function line #1378 state = conn.poll() )
> In the asynchronous connection, after executing the query, the conn.poll()
> is being called to fetch the connection status.
> It gives the status accordingly but in this case, it is blocking and not
> giving the status.
>

If I put a breakpoint on the _wait_timeout call (line 969 in
execute_async), it hits it *after* the 30 seconds has passed (during which
time all other queries for cancel or dashboards and status etc don't get
processed).

If I walk down the call stack, it returns from the _cursor.execute call in
cursor.py and then hangs right before it goes into _wait_timeout.

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

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

Re: Async queries pretending to be synchronous

[Khushboo Vashi]

On Mon, Mar 4, 2019 at 3:43 PM Dave Page  wrote:

> Hi
>
> On Mon, Mar 4, 2019 at 5:43 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Mar 1, 2019 at 10:01 PM Dave Page  wrote:
>>
>>> In investigating #3656 I found the initial problem to be that when
>>> running in a container, Gunicorn will kill the worker process if a thread
>>> doesn't respond for 30 seconds by default. I fixed that by making the
>>> timeout match the application session timeout, but it revealed another
>>> issue.
>>>
>>> Given the function below (from the ticket), if you open the query tool
>>> and run:
>>>
>>> SELECT 1; SELECT fails_after(30);
>>>
>>> the async query actually blocks for 30 seconds in the cur.execute() call
>>> in execute_async() in connection.py (line 968). This causes the entire app
>>> to hang (watch the dashboard requests pile up in pending state in the
>>> network tab of the browser dev tools).
>>>
>>> If you run just the second SELECT, it works as expected, as does running
>>> something like:
>>>
>>> SELECT 1; SELECT pg_sleep(30);
>>>
>>> Anyone have any idea what's going on?
>>>
>>
>> Connection.poll() blocking the call here. ( connection.py -  _wait_timeout
>> function line #1378 state = conn.poll() )
>> In the asynchronous connection, after executing the query, the
>> conn.poll() is being called to fetch the connection status.
>> It gives the status accordingly but in this case, it is blocking and not
>> giving the status.
>>
>
> If I put a breakpoint on the _wait_timeout call (line 969 in
> execute_async), it hits it *after* the 30 seconds has passed (during which
> time all other queries for cancel or dashboards and status etc don't get
> processed).
>
> Put the breakpoint  in the _wait_timeout function itself. The line no
1378  (state = conn.poll()) is blocking the execution 30 seconds.

> If I walk down the call stack, it returns from the _cursor.execute call in
> cursor.py and then hangs right before it goes into _wait_timeout.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Async queries pretending to be synchronous

[Dave Page]

On Mon, Mar 4, 2019 at 10:18 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Mon, Mar 4, 2019 at 3:43 PM Dave Page  wrote:
>
>> Hi
>>
>> On Mon, Mar 4, 2019 at 5:43 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 1, 2019 at 10:01 PM Dave Page  wrote:
>>>
 In investigating #3656 I found the initial problem to be that when
 running in a container, Gunicorn will kill the worker process if a thread
 doesn't respond for 30 seconds by default. I fixed that by making the
 timeout match the application session timeout, but it revealed another
 issue.

 Given the function below (from the ticket), if you open the query tool
 and run:

 SELECT 1; SELECT fails_after(30);

 the async query actually blocks for 30 seconds in the cur.execute()
 call in execute_async() in connection.py (line 968). This causes the entire
 app to hang (watch the dashboard requests pile up in pending state in the
 network tab of the browser dev tools).

 If you run just the second SELECT, it works as expected, as does
 running something like:

 SELECT 1; SELECT pg_sleep(30);

 Anyone have any idea what's going on?

>>>
>>> Connection.poll() blocking the call here. ( connection.py -  _wait_timeout
>>> function line #1378 state = conn.poll() )
>>> In the asynchronous connection, after executing the query, the
>>> conn.poll() is being called to fetch the connection status.
>>> It gives the status accordingly but in this case, it is blocking and not
>>> giving the status.
>>>
>>
>> If I put a breakpoint on the _wait_timeout call (line 969 in
>> execute_async), it hits it *after* the 30 seconds has passed (during which
>> time all other queries for cancel or dashboards and status etc don't get
>> processed).
>>
>> Put the breakpoint  in the _wait_timeout function itself. The line no
> 1378  (state = conn.poll()) is blocking the execution 30 seconds.
>
>> If I walk down the call stack, it returns from the _cursor.execute call
>> in cursor.py and then hangs right before it goes into _wait_timeout.
>>
>
Hmm, yeah - my debugger is doing some weird off-by-one thing. If I put the
break point on the while 1, it blocks there! If I put it on the poll()
call, then it does do as you describe.

So, any idea why it's blocking, before I spend more time digging in?

Thanks!

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

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

Re: Async queries pretending to be synchronous

[Khushboo Vashi]

On Mon, Mar 4, 2019 at 4:00 PM Dave Page  wrote:

>
>
> On Mon, Mar 4, 2019 at 10:18 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Mon, Mar 4, 2019 at 3:43 PM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Mon, Mar 4, 2019 at 5:43 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Fri, Mar 1, 2019 at 10:01 PM Dave Page  wrote:

> In investigating #3656 I found the initial problem to be that when
> running in a container, Gunicorn will kill the worker process if a thread
> doesn't respond for 30 seconds by default. I fixed that by making the
> timeout match the application session timeout, but it revealed another
> issue.
>
> Given the function below (from the ticket), if you open the query tool
> and run:
>
> SELECT 1; SELECT fails_after(30);
>
> the async query actually blocks for 30 seconds in the cur.execute()
> call in execute_async() in connection.py (line 968). This causes the 
> entire
> app to hang (watch the dashboard requests pile up in pending state in the
> network tab of the browser dev tools).
>
> If you run just the second SELECT, it works as expected, as does
> running something like:
>
> SELECT 1; SELECT pg_sleep(30);
>
> Anyone have any idea what's going on?
>

 Connection.poll() blocking the call here. ( connection.py -  _wait_timeout
 function line #1378 state = conn.poll() )
 In the asynchronous connection, after executing the query, the
 conn.poll() is being called to fetch the connection status.
 It gives the status accordingly but in this case, it is blocking and
 not giving the status.

>>>
>>> If I put a breakpoint on the _wait_timeout call (line 969 in
>>> execute_async), it hits it *after* the 30 seconds has passed (during which
>>> time all other queries for cancel or dashboards and status etc don't get
>>> processed).
>>>
>>> Put the breakpoint  in the _wait_timeout function itself. The line no
>> 1378  (state = conn.poll()) is blocking the execution 30 seconds.
>>
>>> If I walk down the call stack, it returns from the _cursor.execute call
>>> in cursor.py and then hangs right before it goes into _wait_timeout.
>>>
>>
> Hmm, yeah - my debugger is doing some weird off-by-one thing. If I put the
> break point on the while 1, it blocks there! If I put it on the poll()
> call, then it does do as you describe.
>
It's a psycopg2 call, it should return the specific status but it doesn't,
so right now I am digging the Psycopg2 code.

>
> So, any idea why it's blocking, before I spend more time digging in?
>
> Thanks!
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

pgAdmin 4 commit: Fix regression issue caused due to encoding fixes.

[Akshay Joshi]

Fix regression issue caused due to encoding fixes.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=efeb9d6d20d6e927d8a9128bce3e048990a8ebb6
Author: Khushboo Vashi 

Modified Files
--
web/pgadmin/utils/driver/psycopg2/connection.py | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

Re: [pgAdmin4][Patch] - Encoding Fixes

[Akshay Joshi]

Thanks patch applied.

On Sat, Mar 2, 2019 at 11:44 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch for the regression fix.
>
> Thanks,
> Khushboo
>
> On Fri, Mar 1, 2019 at 9:41 PM Dave Page  wrote:
>
>> Hi
>>
>> Unfortunately this has introduced a regression:
>>
>> - Start pgAdmin from the command line or PyCharms.
>> - Connect to a server, open a query tool and run a query (SELECT 1 will
>> do).
>> - Stop and restart the pgAdmin server.
>> - Execute the query again in the client.
>>
>> The error "'Connection' object has no attribute 'python_encoding'" is
>> returned in the messages tab and the following exception is given on the
>> pgAdmin server:
>>
>> 2019-03-01 16:07:26,293: ERROR pgadmin: 'Connection' object has no
>> attribute 'python_encoding'
>> Traceback (most recent call last):
>>   File
>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/app.py",
>> line 1612, in full_dispatch_request
>> rv = self.dispatch_request()
>>   File
>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/app.py",
>> line 1598, in dispatch_request
>> return self.view_functions[rule.endpoint](**req.view_args)
>>   File
>> "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask_login.py",
>> line 792, in decorated_view
>> return func(*args, **kwargs)
>>   File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/__init__.py", line
>> 321, in start_query_tool
>> sql, trans_id, session, connect
>>   File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/utils/start_running_query.py",
>> line 87, in execute
>> transaction_object
>>   File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/utils/start_running_query.py",
>> line 136, in __execute_query
>> status, result = conn.execute_async(sql)
>>   File
>> "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/connection.py",
>> line 939, in execute_async
>> encoding = self.python_encoding
>> AttributeError: 'Connection' object has no attribute 'python_encoding'
>>
>> I'm guessing there's a codepath in which connection objects are created
>> without the python_encoding attribute.
>>
>>
>>
>> On Fri, Mar 1, 2019 at 1:54 PM Dave Page  wrote:
>>
>>> Thanks, applied.
>>>
>>> On Fri, Mar 1, 2019 at 7:06 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi,

 Please find the attached patch to support all the supported encodings
 by PostgreSQL.

 Thanks,
 Khushboo

 On Thu, Feb 28, 2019 at 10:53 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Wed, Feb 27, 2019 at 4:57 PM Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Feb 26, 2019 at 9:01 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> Please find the attached patch to fix the encoding related issues.
>>>
>>> #3992 - View data causes errors with DB encoding EUC_JIS_2004
>>> #3982 - Encoding Problem with PGAdmin 4.2
>>> #3911 - Data output does not display Arabic in WIN1256 encoding
>>> database
>>> - The CSV download for the same encoding has also been fixed.
>>>
>>> I have tested the patch on Python 2.7, 3.5, 3.6 and 3.7.
>>>
>>
>> You've added a couple of new encodings, but it seems to me that we
>> should just add everything that PostgreSQL supports. For example, we now
>> have win1256, but what about 866, 874, 1250, 1251 etc?
>>
>> The full list is at https://www.postgresql.org/docs/11/multibyte.html
>>
>> Any reason not to do that?
>>
> I thought to fix the reported bugs first and after that, I was about
> to add a new ticket to add the remaining supported encodings.
> But as per you, I will add the remaining encodings along with these
> fixes.
>
>>
>>
> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

pgAdmin 4 commit: Prevent auto-commit/rollback being changed mid-transa

[Dave Page]

Prevent auto-commit/rollback being changed mid-transaction, and make the 
Preferences the defaults, not the current values.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0aeb20ee64fef96f4807dfcc4915251798e3137a
Author: Akshay Joshi 

Modified Files
--
.../static/js/sqleditor/query_tool_preferences.js  | 14 
web/pgadmin/tools/datagrid/__init__.py |  6 ++
web/pgadmin/tools/sqleditor/__init__.py| 86 --
web/pgadmin/tools/sqleditor/static/js/sqleditor.js | 22 --
.../tools/sqleditor/tests/test_start_query_tool.py |  6 +-
.../sqleditor/utils/query_tool_preferences.py  |  8 +-
6 files changed, 46 insertions(+), 96 deletions(-)

Re: [pgAdmin4][Patch]: RM #3659 Query tool does not give warning when Auto Commit is turned on in an incomplete transaction

[Dave Page]

Thanks - applied. Works nicely now :-)

On Sat, Mar 2, 2019 at 7:57 AM Akshay Joshi 
wrote:

> Hi Dave
>
> On Fri, Mar 1, 2019 at 8:47 PM Dave Page  wrote:
>
>> Hi
>>
>> On Fri, Mar 1, 2019 at 9:07 AM Akshay Joshi <
>> akshay.jo...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>>
>>> Attached is the patch to fix RM #3659 "Query tool does not give warning
>>> when Auto Commit is turned on in an incomplete transaction".
>>>
>>> Please review it.
>>>
>>
>> The behaviour doesn't seem quite right here. I see two issues:
>>
>> 1) It complains that a transaction is in progress if I try to turn
>> auto-commit on in a freshly opened Query Tool. As I haven't done anything
>> yet, I shouldn't get the warning. I think the logic to determine whether or
>> not we're in a transaction isn't correct.
>>
>> 2) In the case above, the setting is changed anyway. I think this has the
>> potential to be confusing (and potentially dangerous); we should only allow
>> the setting to actually be toggled when there's no transaction in progress.
>>
>
>The above behaviour I have followed from pgAdmin 3.
>
>>
>> Given 2), I wonder if we should remove the warning entirely, and just
>> disable the menu options whenever a transaction is in progress.
>>
>
> Done. I have disabled the drop down button when transaction is in
> progress. I have tried to disabled single menu option but that is an anchor
> tag. I have tried with CSS by setting "*pointer-events: none*" and from
> HTML adding "*disabled=’disabled*’" which is only supported in old
> browsers.
>
> Attached is the updated patch, please review it.
>
>>
>> I've attached an updated patch - I started tweaking the messages, so
>> please base additional work from that.
>>
>> Thanks.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
> --
> *Akshay Joshi*
>
> *Sr. Software Architect *
>
>
>
> *Phone: +91 20-3058-9517Mobile: +91 976-788-8246*
>


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

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

pgAdmin 4 commit: Fix the position of text editor of a cell in Query To

[Akshay Joshi]

Fix the position of text editor of a cell in Query Tool.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=98815af8b6a2ed9590e702be6c7e111309eec3c3
Author: Khushboo Vashi 

Modified Files
--
web/pgadmin/static/js/slickgrid/editors.js | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)

Re: Result grid rendering (was: Re: [pgAdmin4][Pattch] - RM #3673 - "Download as .csv" F8 does NOT work when one of joined files is a TEMPORARY file)

[Akshay Joshi]

Thanks patch applied. I am not able to reproduce the issue that Dave has
mentioned.

On Mon, Mar 4, 2019 at 3:43 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Mar 1, 2019 at 6:19 PM Dave Page  wrote:
>
>>
>>
>> On Fri, Mar 1, 2019 at 5:39 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> Please find the attached fix.
>>>
>>> Thanks,
>>> Khushboo
>>>
>>>
>>> On Thu, Feb 28, 2019 at 6:58 PM Dave Page  wrote:
>>>
 Hi

 On Thu, Feb 28, 2019 at 3:46 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Dave,
>
> On Wed, Feb 27, 2019 at 4:30 PM Dave Page  wrote:
>
>> Hi
>>
>> Thanks - that fixed the double scrollbar, but not the other issue.
>> Any ideas on that one?
>>
> Can you please provide the exact steps to reproduce the second issue
> as after fixing the first one I can't reproduce it.
>

 Sure - movie seems easiest, so grab some popcorn and put the attached
 on the big screen!

>>> Unfortunately, I don't have a big screen, so I missed the opportunity to
>>> have popcorn. :)
>>>
>>
>> Booo :-(
>>
>> Well, anyway - the sizing issue seems OK now, but if I have a table (id
>> serial primary key, data text) with enough rows that I need to scroll, when
>> I scroll to the end I can edit the id field in place, but the text editor
>> popup doesn't show up. If I try to edit a row further up, it seems to
>> appear in a weird place, so I suspect it's just rendering off-screen.
>>
>> I think we should render it directly against the cell - above if the cell
>> is >50% down in the overall screen, else above, and something similarly
>> sane for the left/right.
>>
>> Not sure if this is a regression or not, but it's unusable as-is, so can
>> you fix that too? I'll commit your current patch.
>>
>> I couldn't reproduce the issue, however, I found that the position of the
> text area was not appropriate.
> To fix this, I have applied below logic.
>
> Textarea Top = Current Cell Top - Text area Height
>
> So, in this case, the text area bottom would align with the cell itself.
>
> Please find the patch along with the screen-shots.
>
> Thanks!
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Re: Interested in GSoC projects on pgAdmin 4

[Dave Page]

Hi

[Moving pgsql-hackers to BCC to prevent further cross-posting]

On Sat, Mar 2, 2019 at 12:36 AM Haoran Yu  wrote:

> Dear PostgreSQL community:
>
> I am a MSc student in computer science working on data management
> research, and I will likely graduate this summer. I also was a participant
> of GSoC in 2017 working with the NRNB organization on data standards
> conversion.
>

Cool.


>
> I have been a user of pgAdmin 4 briefly, and I am interested in learning
> more about the project and contribute to it. The projects web page lists 3
> potential projects, but I don't know which one I'm suitable for. Are there
> any suggestions on how to get started on exploring more about the Query
> Tool in pgAdmin? For example, use cases with some sample data would be
> nice! I also checked out the pgadmin4 repository from git, and I'll start
> exploring the code shortly.
>

The choice of which project to work on is entirely down to your own
personal interests. You can even propose something else if you like, though
the listed projects are ones that are likely to be accepted as they're
known to be valuable.

The first project (Query Tool Graphing) has a simple use case of allowing
any user to quickly render a graph of their data. More specific use cases
can be discussed as part of the project, but quite simply the idea is to
allow users a quick and easy way to visualise their data. It would probably
help to install PostGIS in a database, and then load the test data we used
to play with it and see how that works (see
https://www.postgresql.org/message-id/CAA7HE_cU7bmQv1kdPB3hiKYGJLaOVVft_XxqcD6ueJpAGfqykQ%40mail.gmail.com
- specifically, the Google Drive link). The GIS viewer is similar to what I
have in mind for this feature, except that instead of drawing maps, we'd
draw different types of graphs.

The second project is about supporting bytea in the Query Tool. Right now
bytea data isn't rendered when you run a query - we show a placeholder
instead. The use case here is for users that store media files in bytea
columns; we want to be able to automatically detect different file types
and allow them to be viewed (or listened to) in the tool. When running in
Edit more, the user should be able to add or replace data in a row by
uploading from the browser. I don't have any sample data for this.

The final project listed is a long-term design goal of pgAdmin 4 (and
probably the hardest project). In pgAdmin 3 we had separate Query Tool and
View/Edit data tools. In pgAdmin 4, we made them into the same tool, but
running in two separate modes. The use case here is to prevent the need for
the user to choose what mode to open the tool in (Query Tool vs. View/Edit
Data), and to automatically detect whether any query would produce an
updateable resultset. This would allow the tool to offer all features at
all times, and simple enable/disable in-place editing of the query results
if there's no way to automatically generate an update/insert/delete
statement. This one is potentially hard as it will likely require some
amount of parsing of the query string to make that determination. You can
simply play with any test data to get a feel for this one.

Hope this helps.

Regards, Dave.

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

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

pgAdmin 4 commit: Update message catalogs.

[Akshay Joshi]

Update message catalogs.

Branch
--
master

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

Modified Files
--
web/pgadmin/messages.pot   | 2366 +++---
.../translations/de/LC_MESSAGES/messages.mo|  Bin 147380 -> 148467 bytes
.../translations/de/LC_MESSAGES/messages.po| 2399 +++---
.../translations/es/LC_MESSAGES/messages.mo|  Bin 152267 -> 153345 bytes
.../translations/es/LC_MESSAGES/messages.po| 2409 +++---
.../translations/fr/LC_MESSAGES/messages.mo|  Bin 156198 -> 157168 bytes
.../translations/fr/LC_MESSAGES/messages.po| 3332 ++--
.../translations/ja/LC_MESSAGES/messages.mo|  Bin 162736 -> 163726 bytes
.../translations/ja/LC_MESSAGES/messages.po| 2410 +++---
.../translations/ko/LC_MESSAGES/messages.mo|  Bin 149862 -> 150936 bytes
.../translations/ko/LC_MESSAGES/messages.po| 2406 +++---
.../translations/pl/LC_MESSAGES/messages.mo|  Bin 147635 -> 148695 bytes
.../translations/pl/LC_MESSAGES/messages.po| 2409 +++---
.../translations/ru/LC_MESSAGES/messages.mo|  Bin 185459 -> 186369 bytes
.../translations/ru/LC_MESSAGES/messages.po| 2406 +++---
.../translations/zh/LC_MESSAGES/messages.mo|  Bin 126587 -> 127714 bytes
.../translations/zh/LC_MESSAGES/messages.po| 2396 +++---
17 files changed, 11657 insertions(+), 10876 deletions(-)

pgAdmin 4 commit: Update version for release

[Akshay Joshi]

Update version for release

Branch
--
master

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

Modified Files
--
runtime/Info.plist   | 4 ++--
runtime/pgAdmin4.pro | 2 +-
web/config.py| 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)

pgAdmin4 v4.3 candidate builds

[Akshay Joshi]

Hi All,

pgAdmin4 v4.3 candidate builds and source can be found at https://developer.
pgadmin.org/builds/2019-03-04-2/

Fahar, can you please verify it for release on Thursday.

-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Japanese translation for v4.3

[fn ln]

 Hello.
Updated Japanese translation for upcoming version 4.3 is in attachment.
Message catalog is based on git 9ad8756e.


pgadmin4-4.3-ja.7z
Description: Binary data

pgAdmin 4 commit: Add support for reverse proxied setups with Gunicorn,

[Dave Page]

Add support for reverse proxied setups with Gunicorn, and document Gunicorn, 
uWSGI & NGINX configurations. Fixes #2001

Branch
--
master

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

Modified Files
--
docs/en_US/release_notes.rst |   1 +
docs/en_US/release_notes_4_4.rst |  16 +
docs/en_US/server_deployment.rst | 126 ++-
web/pgAdmin4.py  |  22 +++
4 files changed, 164 insertions(+), 1 deletion(-)

Fwd: gsoc 2019

[Victor Kukshiev]

-- Forwarded message -
From: Victor Kukshiev 
Date: пн, 4 мар. 2019 г. в 23:15
Subject: gsoc 2019
To: 


Hello! I want to add bytea support or automatic mode detection to query
tool  of Pgadmin..
I known Html, Python and js is not ideal, but ready to learn, I like
learn...
How to participate?
https://wiki.postgresql.org/wiki/GSoC_2019#pgAdmin_4_Query_Tool_bytea_support_.282019.29
https://wiki.postgresql.org/wiki/GSoC_2019#pgAdmin_4_Query_Tool_automatic_mode_detection_.282019.29

Re: Async queries pretending to be synchronous

[Khushboo Vashi]

On Mon, Mar 4, 2019 at 4:05 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Mon, Mar 4, 2019 at 4:00 PM Dave Page  wrote:
>
>>
>>
>> On Mon, Mar 4, 2019 at 10:18 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Mon, Mar 4, 2019 at 3:43 PM Dave Page  wrote:
>>>
 Hi

 On Mon, Mar 4, 2019 at 5:43 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Mar 1, 2019 at 10:01 PM Dave Page  wrote:
>
>> In investigating #3656 I found the initial problem to be that when
>> running in a container, Gunicorn will kill the worker process if a thread
>> doesn't respond for 30 seconds by default. I fixed that by making the
>> timeout match the application session timeout, but it revealed another
>> issue.
>>
>> Given the function below (from the ticket), if you open the query
>> tool and run:
>>
>> SELECT 1; SELECT fails_after(30);
>>
>> the async query actually blocks for 30 seconds in the cur.execute()
>> call in execute_async() in connection.py (line 968). This causes the 
>> entire
>> app to hang (watch the dashboard requests pile up in pending state in the
>> network tab of the browser dev tools).
>>
>> If you run just the second SELECT, it works as expected, as does
>> running something like:
>>
>> SELECT 1; SELECT pg_sleep(30);
>>
>> Anyone have any idea what's going on?
>>
>
> Connection.poll() blocking the call here. ( connection.py -  _wait_timeout
> function line #1378 state = conn.poll() )
> In the asynchronous connection, after executing the query, the
> conn.poll() is being called to fetch the connection status.
> It gives the status accordingly but in this case, it is blocking and
> not giving the status.
>

 If I put a breakpoint on the _wait_timeout call (line 969 in
 execute_async), it hits it *after* the 30 seconds has passed (during which
 time all other queries for cancel or dashboards and status etc don't get
 processed).

 Put the breakpoint  in the _wait_timeout function itself. The line no
>>> 1378  (state = conn.poll()) is blocking the execution 30 seconds.
>>>
 If I walk down the call stack, it returns from the _cursor.execute call
 in cursor.py and then hangs right before it goes into _wait_timeout.

>>>
>> Hmm, yeah - my debugger is doing some weird off-by-one thing. If I put
>> the break point on the while 1, it blocks there! If I put it on the poll()
>> call, then it does do as you describe.
>>
> It's a psycopg2 call, it should return the specific status but it doesn't,
> so right now I am digging the Psycopg2 code.
>

If I remove RAISE statements and then execute SELECT 1; SELECT
fails_after(30); it works as expected.

As per the documentation,  (Ref:
http://initd.org/psycopg/docs/connection.html)
Connection.poll returns one of the constants defined in Poll constants
. If it
returns POLL_OK

then
the connection has been established or the query results are available on
the client. Otherwise wait until the file descriptor returned by fileno()
 is ready
to read or to write.

So, in case of Raise no file descriptor to read or write, and so before
raising the notice, It will block the connection till the pg_sleep
completes.

>
>> So, any idea why it's blocking, before I spend more time digging in?
>>
>> Thanks!
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>