Re: pgsql: Add TAP tests for contrib/sslinfo

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add TAP tests for contrib/sslinfo
Date: 2021-11-30 21:31:07
Message-ID: 887628C4-6E1C-4DE5-BA8E-4252BA2B1A0D@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

> On 30 Nov 2021, at 21:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> Scratch that, all the copying for tests 001 through 003 had failed. I clearly
>> need another coffee.
>> The question still stands though, does anyone have any ideas on what could've
>> happened as I'm currently drawing a blank?
>
> Dunno, but it strikes me that the libpq code issuing this error is not up
> to our usual quality standards. It's just assuming that the stat()
> failure is ENOENT, and I have a sneaking suspicion that that's not so.
>
> I'm inclined to suggest that we start by changing that code
> to look like, say,
>
> if (stat(fnbuf, &buf) != 0)
> ...
>
> and see what we learn.

That seems like a change worthy of doing regardless, so +1 on trying this. We
can't use %m in frontend though can we? Isn't using strerror_r() like in the
attached what we need to do? If so I can go ahead and do that, and it
shouldn't make the buildfarm any worse off than it is, and ideally we'll get
clues as to why msys is happy to copy the files with Perl but not read them
from C.

--
Daniel Gustafsson https://vmware.com/

Attachment Content-Type Size
libpq_enoent.diff application/octet-stream 847 bytes

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2021-11-30 21:36:17 Re: pgsql: Add TAP tests for contrib/sslinfo
Previous Message Tom Lane 2021-11-30 20:55:00 Re: pgsql: Add TAP tests for contrib/sslinfo