Re: elog levels for _redo failures

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: elog levels for _redo failures
Date: 2007-11-20 20:03:23
Message-ID: 1195589003.4217.350.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2007-11-20 at 14:46 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > I notice that there is some variation in the way that different rmgrs
> > use elog levels.
>
> > Heap uses PANIC always
> > BTree uses LOG and PANIC
> > GIN uses ERROR always
> > GIST uses ERROR always
>
> > Is there a particular reason or benefit for this much variation in the
> > code paths for each rmgr? Why do the log levels vary?
>
> There really isn't any difference between ERROR and PANIC in this
> context: any error is going to result in startup failure (cf. elog.c's
> behavior when there is no exception catcher). I think that the older rmgr
> code may have been written using PANIC to make it more obvious that that
> would happen, but it doesn't matter.

That's what I thought.

> Not sure if there's much point in
> trying to standardize.

OK, as long its a conscious decision.

We'll need to be more careful in 8.4. I'd suggest indexes at ERROR and
heap at PANIC.

> The stuff that is LOG should perhaps be reduced to DEBUG1 --- I doubt
> that it has any non-debugging purpose.

I'd rather keep seeing it. Only bugs should show up, so I'd like to see
them in the log if the server crashes.

I'm still worried about the code that doesn't LOG at all, but if you're
not worried then I'll let that rest.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-11-20 20:23:20 Re: Simplifying Text Search
Previous Message Tom Lane 2007-11-20 19:46:59 Re: elog levels for _redo failures