pgAdmin 4 commit: Japanese translation update.

[Dave Page]

Japanese translation update.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=64a9e8cb8397d8eefb5aba243dab7909bf24e622
Author: Identifier Anonymous 

Modified Files
--
.../translations/ja/LC_MESSAGES/messages.mo| Bin 163726 -> 164203 bytes
.../translations/ja/LC_MESSAGES/messages.po|  82 ++---
2 files changed, 41 insertions(+), 41 deletions(-)

Re: Japanese translation for v4.3

[Dave Page]

Thanks - update committed.

On Mon, Mar 4, 2019 at 4:02 PM fn ln  wrote:

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


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

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

pgAdmin 4 commit: French translation update.

[Dave Page]

French translation update.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=48c98641847420ef56a18267e8bab8d2af77765e
Author: Fred Escallier 

Modified Files
--
.../translations/fr/LC_MESSAGES/messages.mo|  Bin 157168 -> 157591 bytes
.../translations/fr/LC_MESSAGES/messages.po| 1009 ++--
2 files changed, 496 insertions(+), 513 deletions(-)

Re: fr translation for update

[Dave Page]

Thanks - updated committed.

On Tue, Mar 5, 2019 at 7:14 AM  wrote:

> Hi
> here's the french translation update
> for upcoming version
> Fred
>
>

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

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

Re: gsoc 2019

[Dave Page]

Hi

On Mon, Mar 4, 2019 at 9:38 PM Victor Kukshiev 
wrote:

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

You need to figure out which one you want to work on, then write a proposal
and submit it to the GSoC process (which I don't have any knowledge of).

I would suggest checking out the pgAdmin code from GIT, and making sure you
can run the Python/JS parts on your system (you might want to work in
PyCharm), then start working to understand the areas of the code you'd be
working on. When you have specific questions on how to build/run or how the
code works, feel free to post them here.

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

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

pgAdmin 4 commit: String review and subsequent cleanup

[Dave Page]

String review and subsequent cleanup

Ashesh Vashi
Abhilasha Narendra
Karen Blatchley
Susan Douglas
Dave Page

Branch
--
master

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

Modified Files
--
.../event_triggers/static/js/event_trigger.js  |  4 ++--
.../databases/languages/static/js/language.js  | 10 
.../static/js/domain_constraints.js|  2 +-
.../databases/schemas/domains/static/js/domain.js  |  4 ++--
.../foreign_tables/static/js/foreign_table.js  |  8 +++
.../static/js/fts_configuration.js |  2 +-
.../schemas/functions/static/js/function.js| 10 
.../functions/static/js/trigger_function.js|  4 ++--
.../schemas/sequences/static/js/sequence.js|  2 +-
.../servers/databases/schemas/static/js/catalog.js |  2 +-
.../servers/databases/schemas/static/js/schema.js  | 28 +++---
.../schemas/tables/column/static/js/column.js  |  4 ++--
.../check_constraint/static/js/check_constraint.js |  2 +-
.../tables/partitions/static/js/partition.js   |  4 ++--
.../schemas/tables/rules/static/js/rule.js |  2 +-
.../databases/schemas/tables/static/js/table.js| 18 +++---
.../schemas/tables/triggers/static/js/trigger.js   |  2 +-
.../databases/schemas/types/static/js/type.js  |  4 ++--
.../databases/schemas/views/static/js/mview.js |  6 ++---
.../databases/schemas/views/static/js/view.js  |  2 +-
.../servers/databases/static/js/database.js| 12 +-
.../resource_groups/static/js/resource_group.js|  2 +-
.../server_groups/servers/roles/static/js/role.js  |  8 +++
.../server_groups/servers/static/js/server.js  |  2 +-
.../servers/tablespaces/static/js/tablespace.js|  4 ++--
web/pgadmin/browser/static/js/node.ui.js   | 12 +-
web/pgadmin/dashboard/static/js/dashboard.js   |  4 ++--
web/pgadmin/static/js/backform.pgadmin.js  |  2 +-
.../tools/debugger/static/js/debugger_ui.js| 10 
29 files changed, 88 insertions(+), 88 deletions(-)

Re: Async queries pretending to be synchronous

[Dave Page]

On Tue, Mar 5, 2019 at 6:36 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

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

Thanks - confirmed, and created a test case for a bug report:
https://github.com/psycopg/psycopg2/issues/856

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

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