Re: [HACKERS] Deadlock with pg_dump?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Deadlock with pg_dump? |
Дата | |
Msg-id | 200703022205.l22M5fi29939@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Deadlock with pg_dump? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Deadlock with pg_dump?
|
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > I can create a global variable to control this, but the new elog level > > seemed cleaner. > > What I don't like about the proposed patch is that it's nonorthogonal. > I see no reason to suppose that LOG is the only possible elevel for > which it might be interesting to suppress the STATEMENT: field. True. > Perhaps the best thing would be to define an additional ereport > auxiliary function, say errprintstmt(bool), that could set a flag > in the current elog stack entry to control suppression of STATEMENT. > This would mean you couldn't determine the behavior when using elog(), > but that's not supposed to be used for user-facing messages anyway. One idea I had was to set the high-bit of elevel to control whether we want to suppress statement logging, but I think errprintstmt() might be best. I don't understand the ereport stack well enough to add this functionality, though. What should I look for? -- 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-patches по дате отправления: