From: | Seino Yuki <seinoyu(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Date: | 2024-10-17 13:15:51 |
Message-ID: | 6971f29d01a0aa12afc8d7ffebd6f6d8@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2024-10-17 13:29:10 | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Previous Message | Ranier Vilela | 2024-10-17 12:35:40 | Re: replace strtok() |