Re: TODO request: log_long_transaction

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Thom Brown <thom(at)linux(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TODO request: log_long_transaction
Date: 2014-11-08 02:16:45
Message-ID: CA+TgmoaO8-2KbAOzJ5kOqmu2JGNZzvhU6HyzivgH1fxvWv_i5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

You should add this patch here, so it doesn't get forgotten:

https://commitfest.postgresql.org/action/commitfest_view/open

On Fri, Nov 7, 2014 at 2:19 PM, Michael Banck <michael(dot)banck(at)credativ(dot)de> wrote:
> 1. Should this log when the duration is exceeded (like log_lock_waits),
> or on commit? I guess the latter, cause log_lock_waits is kinda an
> offshoot from the deadlock detector, and other things don't work in a
> similar fashion and/or this might be quite tricky and a non-starter.

Either could be useful. I'm guessing Josh had the latter in mind.

> 2. It would be quite nice to log long-running idle-in-transaction (i.e.
> transactions which have been idle for a long time, not necessarily long
> transactions which are idle every now and then), but see 1.

I agree. You could implement this by setting a timeout when going
idle in transaction.

> 3. Should long transactions which are rolled back be logged as well?

Yes.

> 4. We log the statement when exceeding log_min_duration_statement, but
> for transactions, that does not make a lot of sense, or should the last
> statement be logged? I don't think that would be particularly useful.

This is a potentially serious problem with this whole idea, and the
idea in #2. You can log that it happened, but without some idea of
what it did, it's probably not going to be too useful.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-08 02:20:35 Re: BRIN indexes - TRAP: BadArgument
Previous Message Robert Haas 2014-11-08 02:10:41 Re: Sequence Access Method WIP