On 2025/03/21 15:21, Yuki Seino wrote:
Pushed the patch. Thanks!
Thank you. I'm very happy !!
Using the newly introduced mechanism, we can now easily extend
the log_lock_failure GUC to support additional NOWAIT lock failures,
such as LOCK TABLE ... NOWAIT, ALTER TABLE ... NOWAIT,
ALTER MA
Pushed the patch. Thanks!
Thank you. I'm very happy !!
Using the newly introduced mechanism, we can now easily extend
the log_lock_failure GUC to support additional NOWAIT lock failures,
such as LOCK TABLE ... NOWAIT, ALTER TABLE ... NOWAIT,
ALTER MATERIALIZED VIEW ... NOWAIT, and ALTER INDEX
On 2025/03/11 22:24, Fujii Masao wrote:
On 2025/03/11 16:50, Yuki Seino wrote:
Instead, wouldn't it be simpler to update LockAcquireExtended() to
take a new argument, like logLockFailure, to control whether
a lock failure should be logged directly? I’ve adjusted the patch
accordingly and at
On 2025/03/11 16:50, Yuki Seino wrote:
Instead, wouldn't it be simpler to update LockAcquireExtended() to
take a new argument, like logLockFailure, to control whether
a lock failure should be logged directly? I’ve adjusted the patch
accordingly and attached it. Please let me know what you thin
Instead, wouldn't it be simpler to update LockAcquireExtended() to
take a new argument, like logLockFailure, to control whether
a lock failure should be logged directly? I’ve adjusted the patch
accordingly and attached it. Please let me know what you think!
Regards,
Thank you!
It's very simple
On 2025/03/10 22:11, Yuki Seino wrote:
I encountered a compilation error with the patch. You can also see the error in
the patch tester.
https://cirrus-ci.com/task/5070779370438656
Sorry, removed some errors and made some fixes.
Thanks for updating the patch!
You modified heap_lock_tuple(
I encountered a compilation error with the patch. You can also see the
error in the patch tester.
https://cirrus-ci.com/task/5070779370438656
Sorry, removed some errors and made some fixes.
Regard,
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d2fa5f7d1a9..dd14bac6a4d
On 2025/02/28 21:08, Yuki Seino wrote:
On 2025/02/27 15:44, Yuki Seino wrote:
(4)
https://github.com/postgres/postgres/blob/master/src/backend/access/heap/heapam_handler.c#L463
...I don't know how to reproduce it.
I have confirmed that (4) can be reproduced using the following procedure.
On 2025/02/27 15:44, Yuki Seino wrote:
(4)
https://github.com/postgres/postgres/blob/master/src/backend/access/heap/heapam_handler.c#L463
...I don't know how to reproduce it.
I have confirmed that (4) can be reproduced using the following procedure.
(4)
https://github.com/postgres/postgres
On 2025/02/21 10:28, Fujii Masao wrote:
On 2025/02/20 15:27, Yuki Seino wrote:
On 2025/02/19 1:08, Fujii Masao wrote:
Just an idea, but how about updating ConditionalXactLockTableWait()
to do the followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the
LOCALLOCK va
On 2025/02/20 15:27, Yuki Seino wrote:
On 2025/02/19 1:08, Fujii Masao wrote:
Just an idea, but how about updating ConditionalXactLockTableWait() to do the
followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the LOCALLOCK
value.
- Generate a log message about the l
On 2025/02/19 1:08, Fujii Masao wrote:
Just an idea, but how about updating ConditionalXactLockTableWait() to
do the followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the
LOCALLOCK value.
- Generate a log message about the lock holders, from the retrieved
the LOCALL
On 2025/02/18 18:33, Yuki Seino wrote:
On 2025/02/13 2:31, Jelte Fennema-Nio wrote:
On Wed, 12 Feb 2025 at 12:32, Fujii Masao wrote:
What do you think if we simply don't log anything for SKIP LOCKED?
Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
more complex.
On 2025/02/13 2:31, Jelte Fennema-Nio wrote:
On Wed, 12 Feb 2025 at 12:32, Fujii Masao wrote:
What do you think if we simply don't log anything for SKIP LOCKED?
Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
more complex. I'm fine with focusing on the NOWAIT case f
On Wed, 12 Feb 2025 at 12:32, Fujii Masao wrote:
> > What do you think if we simply don't log anything for SKIP LOCKED?
>
> Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
> more complex. I'm fine with focusing on the NOWAIT case first as an initial
> patch.
I think t
On 2025/02/03 21:30, Yuki Seino wrote:
Thank you for your comment. Sorry for being late.
SELECT FOR UPDATE SKIP LOCKED might skip a large number of rows, leading to
a high volume of log messages from log_lock_failure in your current patch.
Could this be considered unintended behavior? Would
Thank you for your comment. Sorry for being late.
SELECT FOR UPDATE SKIP LOCKED might skip a large number of rows,
leading to
a high volume of log messages from log_lock_failure in your current
patch.
Could this be considered unintended behavior? Would it be better to limit
the number of log
On 2025/01/17 18:29, Yuki Seino wrote:
Thank you for your comments.
+ Currently, only lock failures due to NOWAIT are
+ supported. The default is off. Only superusers
This GUC also affects SKIP LOCKED, so that should be documented.
I overlooked it... I have revised the document
Thank you for your comments.
+ Currently, only lock failures due to NOWAIT are
+ supported. The default is off. Only
superusers
This GUC also affects SKIP LOCKED, so that should be documented.
I overlooked it... I have revised the document with SKIP LOCKED.
If CollectLockHolders
On 2024/12/19 17:21, Yuki Seino wrote:
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3c0fd64fec8ed6fa3987c33f076fcffbc3f268c3
Rebased and added new GUC log_lock_failure and minor fixes. Currently only
NOWAIT errors are supported.
Thanks for updating the patch!
+
I will design a new GUC while ensuring consistency with 'log_lock_waits'.
Regarding the patch, when I applied it to HEAD, it failed to compile
with
the following errors. Could you update the patch to address this?
proc.c:1538:20: error: use of undeclared identifier 'buf'
1538 |
ing a new GUC or extending the existing one
(e.g., log_lock_waits)
is debatable, but I prefer the latter. I'm considering extending
log_lock_waits
to accept a value like "fail". If set to "on" (the current behavior),
detailed logs are generated when the lock wait time exceeds
deadlock_timeout.
On 2024/10/18 19:07, Seino Yuki wrote:
The choice between adding a new GUC or extending the existing one
(e.g., log_lock_waits)
is debatable, but I prefer the latter. I'm considering extending log_lock_waits
to accept a value like "fail". If set to "on" (the current behavior),
detailed logs ar
The choice between adding a new GUC or extending the existing one
(e.g., log_lock_waits)
is debatable, but I prefer the latter. I'm considering extending
log_lock_waits
to accept a value like "fail". If set to "on" (the current behavior),
detailed logs are generated when the lock wait time excee
During our discussion, I also thought it would be useful to provide detailed logs
> for lock waits canceled by user actions or lock_timeout.
Thank you. I understand now.
You want to output the logs based on a different trigger than
log_lock_waits.
At first, I found that strange, but I see no
On 2024/10/18 9:37, Seino Yuki wrote:
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 loc
I will send the version with the GUC parameter added from the previous
patch.
I made some minor code refactoring.
Regards,
--
Yuki Seino
NTT DATA CORPORATION
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 934ef5e469..ff6bde0b49 100644
--- a/doc/src/sgml/config.sgml
+++
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'
On 2024/10/17 22:15, Seino Yuki wrote:
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 co
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
Thank you for Review.
Could you explain how to reproduce this? In my quick test,
lock waits canceled by lock_timeout didn’t report either xid or PID,
so I might be missing something.
It seems to be outputting on my end, how about you?
= Console =
postgres=# SHOW log_lock_waits;
log_loc
On 2024/09/13 20:49, Seino Yuki wrote:
Hello,
I would like to add the information of the PID that caused the failure
when acquiring a lock with "FOR UPDATE NOWAIT".
When "FOR UPDATE" is executed and interrupted by lock_timeout,
xid and PID are output in the logs,
Could you explain how to r
Hello,
I would like to add the information of the PID that caused the failure
when acquiring a lock with "FOR UPDATE NOWAIT".
When "FOR UPDATE" is executed and interrupted by lock_timeout,
xid and PID are output in the logs, but in the case of "FOR UPDATE
NOWAIT",
no information is output, maki
33 matches
Mail list logo
