On 12/8/13 3:08 PM, MauMau wrote:
>>>
>>> #5 is output when the DBA shuts down the replication standby server.
>>> #6 is output when the DBA shuts down the server if he is using any custom
>>> background worker.
>>> These messages are always output. What I'm seeing as a problem is that
>>> FATAL messages are output in a normal situation, which worries the DBA,
>>> and
>>> those messages don't help the DBA with anything. They merely worry the
>>> DBA.
>>
>> While "worry" is something to be avoided not logging messages is not the
>> correct solution. On the project side looking for ways and places to better
>> communicate to the user is worthwhile in the absence of adding additional
>> complexity to the logging system. The user/DBA, though, is expected to
>> learn how the proces works, ideally in a testing environment where worry is
>> much less a problem, and understand that some of what they are seeing are
>> client-oriented messages that they should be aware of but that do not
>> indicate server-level issues by themselves.
>
> I see, It might makes sense to make the DBA learn how the system works, so that more DBAs can solve problems by
themselves. However, I wonder how those messages (just stopping server process by admin request) are useful for the
DBA. If they are useful, why don't other background processes (e.g. archiver, writer, walsender, etc.) output such a
messagewhen stopping? For information, #5 and #6 are not client-oriented.
>
> If we want to keep the messages, I think LOG or DEBUG would be appropriate. How about altering "ereport(FATAL, ...)"
to"ereport(LOG, ...); proc_exit(1)"?
IMNSHO, this isn't a "worry" thing, it's a complete mis-categorization of what's happening. Do we output "FATAL" when
youdisconnect from the database? Something that is happening *by design* should not be considered as "fatal".
I'm not saying we shouldn't log it at all, but it's silly to call it fatal just because the process is going away *when
wedid something that needs to make it go away*.
What makes it worse is what happens if you do something like pg_terminate_backend() on one of those? That *should*
createa fatal error (or at least be treated the same way we treat any other use of pg_terminate_backend()).
So in this case I'm betting the real problem is that an orderly shutdown is calling pg_terminate_backend() or the
equivalent.While that's convenient from a code standpoint, it's inaccurate from an API standpoint.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net