Re: potential stuck lock in SaveSlotToPath()

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2020-04-01T14:26:25Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Drop slot's LWLock before returning from SaveSlotToPath()