Re: [HACKERS] Deadlock with pg_dump?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Deadlock with pg_dump? |
Дата | |
Msg-id | 200703022246.l22Mkeo10707@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: > > Tom Lane wrote: > >> 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? > > It wouldn't really be any different from errcode(), but if you want > I'll do it. If you would just add the infrastructure I can add the LOG part. -- 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 по дате отправления: