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
- 0001-Save-errno-across-LWLockRelease-calls.patch (text/plain)
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
-
Drop slot's LWLock before returning from SaveSlotToPath()
- ce28a43ffa89 9.5.22 landed
- 2d8597ba66a1 9.6.18 landed
- f36a10434a31 10.13 landed
- ba4cc05ce22d 11.8 landed
- 223e9c77dcaf 12.3 landed
- 49bf81536e24 13.0 landed