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
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 |