| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgbf(at)twiska(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: XLogReadRecord() error in XlogReadTwoPhaseData() |
| Date: | 2022-01-24 02:25:04 |
| Message-ID: | 1787748.1642991104@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Sun, Jan 23, 2022 at 06:10:07PM -0800, Noah Misch wrote:
>> Could do that. Every run that doesn't get the flaky failure will print a
>> message like "TODO passed: 3-5", though the test file could mitigate that by
>> declaring the TODO only on configurations where we expect a failure. The
>> 027_stream_regress.pl trouble involves reaching a die(), not failing a test in
>> this sense, so that one would take more work.
> Using a TODO has the advantage to allow the tests to run on a periodic
> basis, even if they could fail in this unexpected way.
I'm okay with this *if* the TODO marking can be constrained to platforms
where we know there's a problem. Otherwise I'm afraid it will mask
unexpected problems.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-01-24 02:25:33 | Re: Bogus duplicate command issued in pg_dump |
| Previous Message | Andres Freund | 2022-01-24 02:24:28 | Re: Replace uses of deprecated Python module distutils.sysconfig |