| От | Peter Eisentraut |
|---|---|
| Тема | Re: potential stuck lock in SaveSlotToPath() |
| Дата | |
| Msg-id | b1969593-6701-bacc-1d33-a86eabf1ca5b@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: potential stuck lock in SaveSlotToPath() (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: potential stuck lock in SaveSlotToPath()
|
| Список | 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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера