| От | torikoshia |
|---|---|
| Тема | Re: adding wait_start column to pg_locks |
| Дата | |
| Msg-id | f9153182845e5584b954ab6f03514d13@oss.nttdata.com обсуждение |
| Ответ на | Re: adding wait_start column to pg_locks (Fujii Masao <masao.fujii@oss.nttdata.com>) |
| Ответы |
Re: adding wait_start column to pg_locks
|
| Список | pgsql-hackers |
On 2021-01-25 23:44, Fujii Masao wrote: > Another comment is; Doesn't the change of MyProc->waitStart need the > lock table's partition lock? If yes, we can do that by moving > LWLockRelease(partitionLock) just after the change of > MyProc->waitStart, but which causes the time that lwlock is being held > to be long. So maybe we need another way to do that. Thanks for your comments! It would be ideal for the consistency of the view to record "waitstart" during holding the table partition lock. However, as you pointed out, it would give non-negligible performance impacts. I may miss something, but as far as I can see, the influence of not holding the lock is that "waitstart" can be NULL even though "granted" is false. I think people want to know the start time of the lock when locks are held for a long time. In that case, "waitstart" should have already been recorded. If this is true, I think the current implementation may be enough on the condition that users understand it can happen that "waitStart" is NULL and "granted" is false. Attached a patch describing this in the doc and comments. Any Thoughts? Regards, -- Atsushi Torikoshi
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера