elog(PANIC) should abort()?

elog(PANIC) should abort()?

Post by Peter Eisentra » Thu, 28 Nov 2002 03:42:43



Quote:Tom Lane writes:
> I am thinking it would be useful for debugging if elog(PANIC) were to
> exit by calling abort() so that a core dump would be produced.

> Going out via proc_exit(), as it now does, seems like a bad idea in any
> case, since that will try to do a bunch of cleanup activity that's
> probably inappropriate after a panic.

But is this appropriate?

PANIC:  The database cluster was initialized with CATALOG_VERSION_NO 200210181,
        but the backend was compiled with CATALOG_VERSION_NO 200211021.
        It looks like you need to initdb.
Aborted (core dumped)

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

 
 
 

elog(PANIC) should abort()?

Post by Tom La » Thu, 28 Nov 2002 10:40:26



> Tom Lane writes:
>> I am thinking it would be useful for debugging if elog(PANIC) were to
>> exit by calling abort() so that a core dump would be produced.
> But is this appropriate?
> PANIC:  The database cluster was initialized with CATALOG_VERSION_NO 200210181,
>         but the backend was compiled with CATALOG_VERSION_NO 200211021.
>         It looks like you need to initdb.
> Aborted (core dumped)

Hm.  We could possibly reduce those particular messages to FATAL.

OTOH, it's not unreasonable that seeing those messages *in the field*
might be an appropriate situation for a core dump.  I think as
developers we sometimes have a skewed sense of what's common ;-)

Ever since Bruce introduced the additional elog levels, I have felt it
would be a good idea to go through all the elog calls and re-evaluate
what levels they should have.  It's a lot o' work though...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command


 
 
 

1. elog(LOG), elog(DEBUG)

There's a TODO item to make elog(LOG) a separate level.  I propose the
name INFO.  It would be identical to DEBUG in effect, only with a
different label.  Additionally, all DEBUG logging should either be
disabled unless the debug_level is greater than zero, or alternatively
some elog(DEBUG) calls should be converted to INFO conditional on a
configuration setting (like log_pid, for example).

The stricter distinction between DEBUG and INFO would also yield the
possibility of optionally sending DEBUG output to the frontend, as has
been requested a few times.

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

2. crystal reports, parameters

3. Talkative initdb, elog message levels

4. data dictionary

5. elog/internationalization thread

6. Binding CTable<CAccessor<AnyTable> > with consumers

7. elog() proposal

8. 16-bit ODBC Text Drivers?

9. pgsql/src/include/utils (elog.h)

10. pgsql/src/backend/utils/error (elog.c)

11. elog() proposal

12. pgsql/src/include/utils (elog.h)