The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
+1.
I checked the patch and there were no problems.
I hope th
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
The patch applies cleanly and looks fine to me. It's a small
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, failed
Spec compliant: tested, passed
Documentation:tested, failed
The patch applies cleanly and looks fine to me.I'm going to l
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
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.
commit;h=3c0fd64fec8ed6fa3987c33f076fcffbc3f268c3
Rebased and added new GUC log_lock_failure and minor fixes. Currently
only NOWAIT errors are supported.
I would like to revisit the possibility of extending this GUC to include
client cancellations and lock timeouts at another opportunity.
--
Regard
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
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/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
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
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/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/pos
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
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
14 matches
Mail list logo
