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
signature.asc
Description: PGP signature
