Re: TODO request: log_long_transaction
От | Robert Haas |
---|---|
Тема | Re: TODO request: log_long_transaction |
Дата | |
Msg-id | CA+TgmoaO8-2KbAOzJ5kOqmu2JGNZzvhU6HyzivgH1fxvWv_i5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TODO request: log_long_transaction (Michael Banck <michael.banck@credativ.de>) |
Ответы |
Re: TODO request: log_long_transaction
|
Список | 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.banck@credativ.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
В списке pgsql-hackers по дате отправления: