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

Btree issues a LOG during forget_matching_split(), but does nothing
during forget_matching_deletion().

GIN and GIST now don't issue any elog at all when they cannot find a
matching split. GIN doesn't complain if it cannot cleanup correctly,
while GIST does.

Is there a particular reason or benefit for this much variation in the
code paths for each rmgr? Why do the log levels vary?

I'm thinking that index rmgr log levels should be either LOG or PANIC,
in this release, plus I would expect to see some more LOGs for when
things don't work right. Or is there no need to PANIC? ;-)

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

Search Discussions

  • Tom Lane at Nov 20, 2007 at 7:47 pm

    Simon Riggs 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. Not sure if there's much point in
    trying to standardize.

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

    regards, tom lane
  • Simon Riggs at Nov 20, 2007 at 8:03 pm

    On Tue, 2007-11-20 at 14:46 -0500, Tom Lane wrote:
    Simon Riggs <simon@2ndquadrant.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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 20, '07 at 11:44a
activeNov 20, '07 at 8:03p
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Simon Riggs: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase