Re: Code paths where LWLock should be released on failure
В списке pgsql-hackers по дате отправления:
| От | Andres Freund |
|---|---|
| Тема | Re: Code paths where LWLock should be released on failure |
| Дата | |
| Msg-id | 20150423074514.GD8239@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Code paths where LWLock should be released on failure (Michael Paquier <michael.paquier@gmail.com>) |
| Список | pgsql-hackers |
Hi,m On 2015-04-23 13:51:57 +0900, Michael Paquier wrote: > After looking at bug #13128, I have been looking at the code around > LWLockAcquire/Release to see if there are similar issues elsewhere. > Here are my findings: Afaics all of these should actually be handled by the paths that release locks upon error. > 5) In ReplicationSlotCreate@slot.c, I would think that > ReplicationSlotAllocationLock should be released when all the locks > are in use. Similarly, in ReplicationSlotDropAcquired, > ReplicationSlotAllocationLock should be released when !fail_softly. > SaveSlotToPath could also be made safer when a file could not be > created. When called via SQL these are released by normal error processing, in walsender they're released by WalSndErrorCleanup(). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера