Skip site navigation (1) Skip section navigation (2)

Re: proposal: additional error fields

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-01 20:14:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 1 May 2012 20:36, Noah Misch <noah(at)leadboat(dot)com> wrote:
> I agree that some means to mechanically distinguish these cases would
> constitute a significant boon for admin monitoring.  Note, however, that the
> same split appears at other severity levels:
> FATAL, routine: terminating connection due to conflict with recovery
> FATAL, critical: incorrect checksum in control file
> WARNING, routine: nonstandard use of escape in a string literal
> WARNING, critical: locallock table corrupted
> We'd be adding at least three new severity levels to cover the necessary
> messages by this approach.

Good point. It might make sense to have an orthogonal property - call
it magnitude - and have that specified alongside the existing severity
levels. However, there's really no point in bothering if all of the
existing elog calls are let off the hook. Someone would need to go
around and assign a value to every existing single elog and ereport
callsite, with the exisiting elog macro signature incrementally
deprecated. Furthermore, I'd support changing the definition of
log_line_prefix within postgresql.conf.sample to include this new
property by default.

This feature will only be a boon to admin monitoring if it's actually
something that there is a reasonable expectation of finding on most or
all Postgres production systems in all circumstances.

Peter Geoghegan
PostgreSQL Development, 24x7 Support, Training and Services

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-05-01 20:14:08
Subject: Re: proposal: additional error fields
Previous:From: Jim NasbyDate: 2012-05-01 20:12:20
Subject: Re: Temporary tables under hot standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group