Re: query that canceled isnt logged

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

In response to

Browse pgsql-performance by date

  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