Re: Adding error message "source"

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding error message "source"
Date: 2009-08-06 14:41:07
Message-ID: 9837222c0908060741l30d507e5o827435d3d533cad7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 6, 2009 at 16:33, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Thu, Aug 6, 2009 at 16:20, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-06 14:47:31 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Previous Message Andrew Dunstan 2009-08-06 14:40:43 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables