Re: EINTR in ftruncate() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: EINTR in ftruncate()
Date
Msg-id 20220711093007.amilmhvnmjt6ygp3@alvherre.pgsql
Whole thread Raw
In response to Re: EINTR in ftruncate()  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On 2022-Jul-07, Thomas Munro wrote:

> On Thu, Jul 7, 2022 at 9:05 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > On Thu, Jul 7, 2022 at 9:03 AM Andres Freund <andres@anarazel.de> wrote:
> > > On 2022-07-07 08:56:33 +1200, Thomas Munro wrote:
> > > > On Thu, Jul 7, 2022 at 8:39 AM Andres Freund <andres@anarazel.de> wrote:
> > > > > So I think we need: 1) block most signals, 2) a retry loop *without*
> > > > > interrupt checks.
> 
> Here's a draft patch that tries to explain all this in the commit
> message and comments.

I gave 0001 a try.  I agree with the approach, and it seems to work as
intended; or at least I couldn't break it under GDB.

I didn't look at 0002, but I wish that the pgstat_report_wait calls were
moved to cover both syscalls in a separate commit, just so we still have
them even if we decide not to do 0002.

Do you intend to get it pushed before the next minors?  I have an
interest in that happening.  Thanks for working on this.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Here's a general engineering tip: if the non-fun part is too complex for you
to figure out, that might indicate the fun part is too ambitious." (John Naylor)
https://postgr.es/m/CAFBsxsG4OWHBbSDM%3DsSeXrQGOtkPiOEOuME4yD7Ce41NtaAD9g%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: CREATE TABLE ( .. STORAGE ..)
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Fix gcc warning in sync.c (usr/src/backend/storage/sync/sync.c)