| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: potential stuck lock in SaveSlotToPath() |
| Date: | 2020-04-01 14:26:25 |
| Message-ID: | b1969593-6701-bacc-1d33-a86eabf1ca5b@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| 0001-Save-errno-across-LWLockRelease-calls.patch | text/plain | 2.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2020-04-01 14:29:54 | Re: WAL usage calculation patch |
| Previous Message | David Steele | 2020-04-01 14:09:44 | Re: Commitfest 2020-03 Now in Progress |