On Thu, Oct 3, 2024 at 3:58 AM David Rowley wrote:
>
> On Tue, 1 Oct 2024 at 21:04, Alexey Orlov wrote:
> > session 1:
> > CREATE TABLE foo (val integer);
> > INSERT INTO foo (val) VALUES (1);
> > BEGIN;
> > UPDATE foo SET val = 3;
> >
> > session 2:
> > BEGIN;
> > UPDATE TABLE foo SET val = 2;
>
On Tue, 1 Oct 2024 at 21:04, Alexey Orlov wrote:
> session 1:
> CREATE TABLE foo (val integer);
> INSERT INTO foo (val) VALUES (1);
> BEGIN;
> UPDATE foo SET val = 3;
>
> session 2:
> BEGIN;
> UPDATE TABLE foo SET val = 2;
>
> LOG: process 3133043 still waiting for ShareLock on transaction 758
> a
On Tue, Oct 1, 2024 at 11:45 AM wenhui qiu wrote:
>
> Hi Alexey Orlov
> Thank you for your work on this path,The lock information is recorded in
> detail,Easy to trace the lock competition at that time there is a detailed
> lock competition log，But I have a concern,Frequent calls to this fu
Hi, there!
I created patch improving the log messages generated by
log_lock_waits.
Sample output (log_lock_waits=on required):
session 1:
CREATE TABLE foo (val integer);
INSERT INTO foo (val) VALUES (1);
BEGIN;
UPDATE foo SET val = 3;
session 2:
BEGIN;
UPDATE TABLE foo SET val = 2;
Output w/o
Hi Alexey Orlov
Thank you for your work on this path,The lock information is recorded
in detail,Easy to trace the lock competition at that time there is a
detailed lock competition log，But I have a concern,Frequent calls to this
function (pgstat_get_backend_current_activity) in heavy lock cont
