Re: Postgres, fsync, and OSs (specifically linux)

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres, fsync, and OSs (specifically linux)
Date: 2018-05-10 01:50:03
Message-ID: CAMsr+YEcv3gvLHX-gTMnA0Z_YCChJ+rCMTGnx1aQMUFmp4Lvbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 May 2018 at 06:55, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Do you have a patchset including that? I didn't find anything after a
> quick search...

There was an earlier rev on the other thread but without msync checks.

I've added panic for msync in the attached, and tidied the comments a bit.

I didn't add comments on why we panic to each individual pg_fsync or
FileSync caller that panics; instead pg_fsync points to
pg_fsync_no_writethrough which explains it briefly and has links.

I looked at callers of pg_fsync, pg_fsync_no_writethrough,
pg_fsync_writethrough, mdsync, and FileSync when writing this.

WAL writing already PANIC'd on fsync failure, which helps, though we
now know that's not sufficient for complete safety.

Patch on top of v11 HEAD @ ddc1f32ee507

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
v2-0001-PANIC-when-we-detect-a-possible-fsync-I-O-error-i.patch text/x-patch 12.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-05-10 02:01:55 Re: Should we add GUCs to allow partition pruning to be disabled?
Previous Message Michael Paquier 2018-05-10 01:37:11 Re: Indexes on partitioned tables and foreign partitions