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 02:21:11
Message-ID: 20200919022111.GB18372@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 18, 2020 at 09:54:42PM -0400, Tom Lane wrote:
> No, absolutely not. That way leads to madness, because you will be trying
> to enforce a system-wide property for the benefit of a few places. There
> is *no code anywhere* that promises to leave errno zero, but what you are
> suggesting will soon lead to a situation where we have to require that of
> everything. It's not sane, it's not maintainable, and it's going to be
> inefficient as heck, because it will require adding a whole lot more
> "errno = 0" statements than the other way.

Well, then what about cleaning up the state for the binaries where it
matters then? FWIW, this example simply fails with an incorrect error
but it should succeed:
--- a/contrib/vacuumlo/t/001_basic.pl
+++ b/contrib/vacuumlo/t/001_basic.pl
@@ -2,8 +2,11 @@ use strict;
use warnings;

use TestLib;
-use Test::More tests => 8;
+use Test::More tests => 9;

program_help_ok('vacuumlo');
program_version_ok('vacuumlo');
program_options_handling_ok('vacuumlo');
+
+command_ok([ 'vacuumlo', '-l', '1', 'postgres' ],
+ 'vacuumlo: error: transaction limit must not be negative (0 disables)');

This makes me wonder if it could not be a real problem in some
environments. vacuumlo is not that used, pg_resetwal though..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-09-19 03:55:24 Re: Division in dynahash.c due to HASH_FFACTOR
Previous Message Justin Pryzby 2020-09-19 02:18:11 Re: Online checksums patch - once again