Re: Add “FOR UPDATE NOWAIT” lock details to the log.
От | Seino Yuki |
---|---|
Тема | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Дата | |
Msg-id | 6971f29d01a0aa12afc8d7ffebd6f6d8@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Add “FOR UPDATE NOWAIT” lock details to the log. (Seino Yuki <seinoyu@oss.nttdata.com>) |
Ответы |
Re: Add “FOR UPDATE NOWAIT” lock details to the log.
|
Список | pgsql-hackers |
>> Considering both points, I’m leaning toward adding a new GUC parameter >> to control whether detailed logs should be generated for failed >> NOWAIT locks (and possibly for those canceled by lock_timeout). >> Alternatively, if adding a new GUC is not ideal, we could extend >> log_lock_waits to accept a new value like 'error,' which would trigger >> detailed logging when a lock wait fails due to NOWAIT, lock_timeout, >> or cancellation. > That's a good idea. I'll try that. Sorry, I misunderstood. The pid and xid are output during deadlock_timeout. > LOG: process 1443346 still waiting for ShareLock on transaction 770 > after 1000.096 ms > DETAIL: Process holding the lock: 1443241. Wait queue: 1443346. This log output is not triggered by lock_timeout or cancellation. Therefore, it is difficult to support lock_timeout and cancellation. I am thinking of supporting only NOWAIT. What do you think? Regards, -- Yuki Seino NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: