| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: Anti-critical-section assertion failure in mcxt.c reached by walsender |
| Date: | 2021-05-08 01:33:12 |
| Message-ID: | YJXqWAuMRd2tIXQs@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-05-08 01:34:04 | Re: Small issues with CREATE TABLE COMPRESSION |
| Previous Message | Tom Lane | 2021-05-08 01:16:49 | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |