| 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-18 00:37:49 |
| Message-ID: | 57d7f8b4a36638896bc0ed382331a021@oss.nttdata.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Currently, we are discussing two improvements:
1. Log output when NOWAIT fails.
2. Adding control via GUC parameters (NOWAIT, lock_timeout,
cancellation).
> I'm not sure why it's challenging to provide detailed log messages for
> lock waits canceled
> by lock_timeout or user cancellation, while it's considered feasible
> for the NOWAIT case.
Does this statement mean that for 2, why can NOWAIT but
lock_timeout,cancellation cannot?
For item 2, the lock_timeout and cancellation will log outputs after the
deadlock_timeout(e.g. 1s) has elapsed (by log_lock_waits).
At the time this log is output, it is unclear whether the lock will be
cancellation or lock_timeout.
This means that the timing at "error is determined" and "output logged"
do not match.
> However, I think it's reasonable to implement this feature step by
> step. We can start
> by adding support for the NOWAIT case and consider extending it to
> handle lock_timeout and
> cancellation scenarios later if possible.
+1.
I will send the version with the GUC parameter added from the previous
patch.
Regards,
--
Yuki Seino
NTT DATA CORPORATION
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-add_loginfo_nowait.patch | text/x-diff | 9.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2024-10-18 00:54:37 | Re: Statistics Import and Export |
| Previous Message | Andy Fan | 2024-10-17 23:36:37 | Re: Considering fractional paths in Append node |