Re: new compiler warnings
От | Tom Lane |
---|---|
Тема | Re: new compiler warnings |
Дата | |
Msg-id | 18263.1319041708@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: new compiler warnings ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: