Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: buildfarm(at)sraoss(dot)co(dot)jp
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Michael Banck <mbanck(at)gmx(dot)net>, Tommy Pavlicek <tommypav122(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, jian(dot)universality(at)gmail(dot)com
Subject: Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Date: 2024-10-27 17:41:54
Message-ID: 3792414.1730050914@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> In the no-good-deed-goes-unpunished department: buildfarm member
> hamerkop doesn't like this patch [1]. The diffs look like
> ...
> So what I'd like to do to fix this is to change
> - if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
> + if ((file = AllocateFile(filename, "r")) == NULL)

Well, that didn't fix it :-(. I went so far as to extract the raw log
files from the buildfarm database, and what they show is that there is
absolutely no difference between the lines diff is claiming are
different:

-QUERY: CREATE FUNCTIN my_erroneous_func(int) RETURNS int LANGUAGE SQL\r\n
+QUERY: CREATE FUNCTIN my_erroneous_func(int) RETURNS int LANGUAGE SQL\r\n

It's the same both before and after 924e03917, which made the code
change depicted above, so that didn't help.

So I'm pretty baffled. I suppose the expected and result files must
actually be different, and something in subsequent processing is
losing the difference before it gets to the buildfarm database.
But I don't have the ability to debug that from here. Does anyone
with access to hamerkop want to poke into this?

Without additional information, the only thing I can think of that
I have any confidence will eliminate these failures is to reformat
the affected test cases so that they produce just a single line of
output. That's kind of annoying from a functionality-coverage point
of view, but I'm not sure avoiding it is worth moving mountains for.

In any case, I'm disinclined to revert 924e03917. It seems like a
good change on balance, even if it failed to fix whatever is
happening on hamerkop.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2024-10-27 17:47:10 libedit history seems to be misbehaving / broken
Previous Message Torsten Förtsch 2024-10-27 12:37:59 Allowing pg_recvlogical to create temporary replication slots