Re: [PATCHES] Deadlock with pg_dump?
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] Deadlock with pg_dump? |
Дата | |
Msg-id | 200702262010.l1QKAnn15959@momjian.us обсуждение исходный текст |
Ответ на | Re: Deadlock with pg_dump? ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: [PATCHES] Deadlock with pg_dump?
|
Список | pgsql-hackers |
Simon Riggs wrote: > On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote: > > > I am a little concerned about a log_* setting that is INFO. I understand > > why you used INFO (for log_min_error_messages), but INFO is inconsistent > > with the log* prefix, and by default INFO doesn't appear in the log > > file. > > Yeh, LOG would be most appropriate, but thats not possible. > > log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, > INFO, NOTICE and WARNING for non-error states. > > Possibly DEBUG1? This highlights a problem we have often had with LOG output where we also want the query. I think there are two possible approaches. First, we could add a new bitmap value like LOG_STATEMENT to ereport when we want the statement with the log line: ereport (LOG | LOG_STATEMENT, ...) (or a new LOG_WITH_STATEMENT log level) and a new GUC like "log_include_statement" that would control the output of statements for certain GUC parameters, and we document with GUC values it controls. A simpler idea would be to unconditionally include the query in the errdetail() of the actual LOG ereport. This is not the first GUC that has needed this. We had this issue with "log_temp_files", which we just added, and the only suggested solution was to use log_statement = 'all'. Either of these ideas above would be useful for this as well. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: