From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com> |
Cc: | "MichaelDBA(at)sqlexec(dot)com" <michaeldba(at)sqlexec(dot)com>, PostgreSQL mailing lists <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: query that canceled isnt logged |
Date: | 2019-12-08 15:42:00 |
Message-ID: | 5943.1575819720@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com> writes:
> If I'll try to run the following query and cancel it manually(ctrl+c) :
> select pg_sleep(10)
> I will see in the logs the following messages :
> 2019-12-08 17:16:34 IST postgres 30797 LOG: statement: select
> pg_sleep(10);
> 2019-12-08 17:16:36 IST postgres 30797 ERROR: canceling statement due to
> user request
> 2019-12-08 17:16:36 IST postgres 30797 STATEMENT: select pg_sleep(10);
Note that that's going through "simple query" protocol (which is why
it says "statement:") but your application is evidently using "extended
query" protocol (because you see "execute ...:", at least when it's
working correctly). I wonder whether the explanation is somewhere in
that.
The best theory I have at the moment, though, is that something is taking
exclusive locks on system catalogs, blocking parsing of even trivial
statements.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lars Aksel Opsahl | 2019-12-08 18:14:14 | Re: How to run in parallel in Postgres, EXECUTE_PARALLEL |
Previous Message | Mariel Cherkassky | 2019-12-08 15:23:01 | Re: query that canceled isnt logged |