"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Unfortunately, the problem we're dealing with here is exactly that
>> we can't write to stderr. So it's a bit hard to see what we can
>> usefully do to report that we have a problem (short of crashing,
>> which isn't a net improvement).
> Are you sure that crashing on an assertion-enabled build *isn't* a
> net improvement?
No, it isn't.
> It sounds like we're pretty convinced this is a
> "can't happen" situation -- if it does happen either the API is not
> honoring its contract or we've badly misinterpreted the contract.
If it happens, the result would be that the syslogger process gets
out-of-sync with the pipe data stream and starts to emit bizarre garbage
(probably what you'd see is weirdly interleaved chunks of messages from
different backends). There have been no such reports from the field
AFAIR. Even if it did happen, I don't think that crashing the backend
is an improvement --- keep in mind that for the first fifteen years of
Postgres' existence, we just tolerated that sort of thing as a matter of
course. Lastly, crashing and restarting the backends *won't fix it*.
The syslogger will still be out of sync, and will stay that way until
random chance causes it to think that a message boundary falls where
there really is one. (Of course, if the assert takes out the postmaster
instead of a backend, it'll be fixed by the manual intervention that
will be required to get things going again.)
We have many better things to spend our time on than worrying about the
hypothetical, unsupported-by-any-evidence-whatsoever risk that the
kernel doesn't meet the POSIX standard on this point.
regards, tom lane