Statement timeout logging

Lists: pgsql-hackers
From: Thom Brown <thom(at)linux(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Statement timeout logging
Date: 2013-06-06 15:01:52
Message-ID: CAA-aLv7gt0HbzVnspWv6wqBD2Bz0YT02JdA3t+53ZxoUvKxdTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi,

When a statement is cancelled due to it running for long enough for
statement_timeout to take effect, it logs a message:

ERROR: canceling statement due to statement timeout

However, it doesn't log what the timeout was at the time of the
cancellation. This may be set in postgresql.conf, the database, or on
the role, but unless log_line_prefix is set to show the database name
and the user name, there's no reliable way of finding out what context
the configuration applied from. Setting log_duration won't help
either because that only logs the duration of completed queries.

Should we output the statement_timeout value when a query is cancelled?

--
Thom


From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Statement timeout logging
Date: 2013-06-06 16:28:18
Message-ID: CAFj8pRA4Q2EtN-TPJAD6ZSsU+nNm009-QuTBwCx2WzwahVQ+9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

2013/6/6 Thom Brown <thom(at)linux(dot)com>:
> Hi,
>
> When a statement is cancelled due to it running for long enough for
> statement_timeout to take effect, it logs a message:
>
> ERROR: canceling statement due to statement timeout
>
> However, it doesn't log what the timeout was at the time of the
> cancellation. This may be set in postgresql.conf, the database, or on
> the role, but unless log_line_prefix is set to show the database name
> and the user name, there's no reliable way of finding out what context
> the configuration applied from. Setting log_duration won't help
> either because that only logs the duration of completed queries.
>
> Should we output the statement_timeout value when a query is cancelled?

+1

we use same feature in GoodData. Our long queries are cancelled by
users and we should to known how much a users would to wait.

Regards

Pavel

>
> --
> Thom
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


From: Thom Brown <thom(at)linux(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Statement timeout logging
Date: 2013-08-30 09:48:47
Message-ID: CAA-aLv4vPCz7uBzkUZ65upt-r1q=9CaTU_=_KZ6MthUB8p6KFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 6 June 2013 17:28, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

> 2013/6/6 Thom Brown <thom(at)linux(dot)com>:
> > Hi,
> >
> > When a statement is cancelled due to it running for long enough for
> > statement_timeout to take effect, it logs a message:
> >
> > ERROR: canceling statement due to statement timeout
> >
> > However, it doesn't log what the timeout was at the time of the
> > cancellation. This may be set in postgresql.conf, the database, or on
> > the role, but unless log_line_prefix is set to show the database name
> > and the user name, there's no reliable way of finding out what context
> > the configuration applied from. Setting log_duration won't help
> > either because that only logs the duration of completed queries.
> >
> > Should we output the statement_timeout value when a query is cancelled?
>
> +1
>
> we use same feature in GoodData. Our long queries are cancelled by
> users and we should to known how much a users would to wait.
>

It seems there are a couple more errors that could share this sort of
information too:

canceling authentication due to timeout
canceling statement due to lock timeout

Admittedly the first of those two isn't really an issue.
--
Thom