Re: Anti-critical-section assertion failure in mcxt.c reached by walsender - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Anti-critical-section assertion failure in mcxt.c reached by walsender
Date
Msg-id YJXqWAuMRd2tIXQs@paquier.xyz
Whole thread Raw
In response to Re: Anti-critical-section assertion failure in mcxt.c reached by walsender  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, May 07, 2021 at 04:30:00PM -0400, Tom Lane wrote:
> I can certainly see an argument for running some buildfarm animals
> with fsync on (for all tests).  I don't see a reason for forcing
> them all to run some tests that way; and if I were going to do that,
> I doubt that 008_fsm_truncation.pl would be the one I would pick.
> I think it's nothing but sloppiness that that one is out of step with
> all the rest.

My take on this point is that using the configuration that can be
enforced for each animal would be enough.  I manage a small animal and
this stuff can take a while to flush some data.

Worth noting that using fsync=on has not been discussed on the
original thread, and I don't see why that's necessary:
https://www.postgresql.org/message-id/flat/CABOikdNr5vKucqyZH9s1Mh0XebLs_jRhKv6eJfNnD2wxTn%3D_9A%40mail.gmail.com
So I would vote for removing it in this case.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Next
From: Michael Paquier
Date:
Subject: Re: Small issues with CREATE TABLE COMPRESSION