Re: pg_logging_init() can return ENOTTY with TAP tests

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_logging_init() can return ENOTTY with TAP tests
Date: 2020-09-19 01:48:58
Message-ID: 20200919014858.GB2841@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-19 01:54:42 Re: pg_logging_init() can return ENOTTY with TAP tests
Previous Message Tom Lane 2020-09-19 01:30:56 Re: Division in dynahash.c due to HASH_FFACTOR