Re: fsync error handling in pg_receivewal, pg_recvlogical

From: Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fsync error handling in pg_receivewal, pg_recvlogical
Date: 2019-07-27 17:02:33
Message-ID: CAH7T-arrc8KQyKUQYpGYL6XaDH-oA7x=+nCUJDZbgfq6Y7P9BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Tried out this patch and it applies, compiles, and passes check-world. Also
flipped things around in pg_recvlogical.c to exit-on-success to ensure it's
actually being called and that worked too. Outside of a more complicated
harness that simulates fsync errors not sure how else to test this further.

I did some searching and found a FUSE based on that looks interesting:
CharybdeFS[1]. Rather than being fixed at mount time, it has a
client/server interface so you can change the handling of syscalls on the
fly[2]. For example you can error out fsync calls halfway through a test
rather than always or randomly. Haven't tried it out but leaving it here as
it seems relevant.

[1]: https://github.com/scylladb/charybdefs
[2]:
https://www.scylladb.com/2016/05/02/fault-injection-filesystem-cookbook/

On Wed, Jun 26, 2019 at 12:11 AM Michael Paquier <michael(at)paquier(dot)xyz>
wrote:

> Why using a different error code. Using EXIT_FAILURE is a more common
> practice in the in-core binaries. The patch looks fine to me except
> that, that's a good first cut.
>

An error code specific to fsync issues could help with tests as the harness
could check it to ensure things died for the right reasons. With a generic
"messed up fsync" harness you might even be able to run some existing tests
that would otherwise pass and check for the fsync-specific exit code.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sehrope Sarkuni 2019-07-27 17:06:06 Re: fsync error handling in pg_receivewal, pg_recvlogical
Previous Message Tom Lane 2019-07-27 16:46:51 Testing LISTEN/NOTIFY more effectively