On Fri, Sep 18, 2020 at 09:56:14AM -0400, Tom Lane wrote:
> No, this is a bad idea. The right place to fix this is whatever code
> segment is relying on errno to be initially zero; that is NEVER a sane
> assumption. That is, a valid coding pattern is something like
It seems to me that it could be a good idea to enforce a rule here
then. There are problems in pg_resetwal and vacuumlo which use
strto[u]l() for option parsing without caring if errno is already set
or not, and we could have a ENOTTY while parsing options. There is
more in the backend code, like assign_recovery_target_timeline() in
guc.c, bootstrap.c, just to notice a few ones. We don't need to go
down to having our own wrapper for strtol() though. There were lately
discussions about removing entirely our dependencies to strtol()
because we mostly rely on base 10 for the parsing and that's the part
impacting performance the most (it is possible to see a clear
difference for some workloads of COPY once you remove the base part).
So for now, what about looking at all those code paths and enforce
errno to 0?
--
Michael
