Re: recovery test failures on hoverfly

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: recovery test failures on hoverfly
Date: 2021-06-12 21:50:46
Message-ID: befdb97b-f8e5-3fea-4ee6-c5d4c94f862c@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 6/12/21 5:28 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I'm a bit dubious about this. It doesn't seem more robust to insist that
>> we pass undef in certain cases.
> True, it'd be nicer if that didn't matter; mainly because people
> will get it wrong in future.

Right, that's what I'm worried about.

>
>> If passing the SQL via stdin is fragile,
>> as we also found to be the case with passing it via the command line,
>> perhaps we should try passing it via a tmp file. Then there would
>> presumably be no SIGPIPE.
> Seems kind of inefficient. Maybe writing and reading a file would
> be a negligible cost compared to everything else involved, but
> I'm not sure.

Well, in poll_query_until we would of course set up the file outside the
loop. I suspect the cost would in fact be negligible.

Note, too that the psql and safe_psql methods also pass the query via stdin.

>
> Another angle is that the SIGPIPE complaints aren't necessarily
> a bad thing: if psql doesn't read what we send, it's good to
> know about that. IMO the real problem is that the errors are
> so darn nonrepeatable. I wonder if there is a way to make them
> more reproducible?
>
>

I don't know.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2021-06-12 21:57:41 Re: unnesting multirange data types
Previous Message Andres Freund 2021-06-12 21:50:03 Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default