Re: Adding error message "source"
От | Magnus Hagander |
---|---|
Тема | Re: Adding error message "source" |
Дата | |
Msg-id | 9837222c0908060741l30d507e5o827435d3d533cad7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Adding error message "source" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Adding error message "source"
|
Список | pgsql-hackers |
On Thu, Aug 6, 2009 at 16:33, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Thu, Aug 6, 2009 at 16:20, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> Well, it seems like you could get 90% of the way there just by filtering >>> on the PID --- watching the bgwriter, walwriter, and archiver should >>> cover this use-case reasonably well. > >> Right. But that's pretty hard to do automated, since they will get a >> new pid whenever the database is restarted. Which is hopefully not >> very often, but still an issue. Plus, it's hard to do any kind of >> historical look at things. > > I don't think there'd be much logical difficulty in having an output > field (ie, CSV column or log_line_prefix escape) that represents a > classification of the PID, say as "postmaster, backend, AV worker, > AV launcher, bgwriter, ...". It would only require changing things > in one place, whereas your original proposal seemed mighty open-ended. Good point. That *would* probably take care of much of the need. The downside is aggressive filtering that way would get rid of important messages coming out of a single backend, like out of disk space. Meaning it would still not be possible to filter on the difference between ERROR: syntax error in query and ERROR: out of disk space? But it'd be an improvement still. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: