Re: potential stuck lock in SaveSlotToPath() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: potential stuck lock in SaveSlotToPath()
Date
Msg-id b1969593-6701-bacc-1d33-a86eabf1ca5b@2ndquadrant.com
Whole thread Raw
In response to Re: potential stuck lock in SaveSlotToPath()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: potential stuck lock in SaveSlotToPath()  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 2020-03-27 08:48, Michael Paquier wrote:
> On Thu, Mar 26, 2020 at 02:16:05PM +0100, Peter Eisentraut wrote:
>> committed and backpatched
> 
> The patch committed does that in three places:
>      /* rename to permanent file, fsync file and directory */
>      if (rename(tmppath, path) != 0)
>      {
> +       LWLockRelease(&slot->io_in_progress_lock);
>     ereport(elevel,
>                  (errcode_for_file_access(),
>                   errmsg("could not rename file \"%s\" to \"%s\": %m",
> 
> But why do you assume that LWLockRelease() never changes errno?  It
> seems to me that you should save errno before calling LWLockRelease(),
> and then restore it back before using %m in the log message, no?  See
> for example the case where trace_lwlocks is set.

Good catch.  How about the attached patch?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Commitfest 2020-03 Now in Progress
Next
From: Julien Rouhaud
Date:
Subject: Re: WAL usage calculation patch