Done. On Mon, Apr 8, 2019 at 9:27 AM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote:
> > > On Tue, Mar 5, 2019 at 10:13 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> 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 <dp...@pgadmin.org> 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 <dp...@pgadmin.org> 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 <dp...@pgadmin.org> >>>>>>>> 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 >>> <http://initd.org/psycopg/docs/extensions.html#poll-constants>. If it >>> returns POLL_OK >>> <http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.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() >>> <http://initd.org/psycopg/docs/connection.html#connection.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 >> >> > This issue has been resolved in psycopg2 v2.8. > @Dave, can you please move it to *in testing* as I couldn't. > >> -- >> 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
