Re: a lot of session wait on lock relation - Mailing list pgsql-performance

From James Pang
Subject Re: a lot of session wait on lock relation
Date
Msg-id CAHgTRfcnPeozVRQUutFmhUffr0fhM-VnLARfs-iBSfrur+bmjQ@mail.gmail.com
Whole thread Raw
In response to Re: a lot of session wait on lock relation  (James Pang <jamespang886@gmail.com>)
List pgsql-performance
Thanks, we are checking the partition maintain job , we have 12 partitions , each week one partition there is a default partition attached with this table and huge rows in default partition too , default partition has primary key that include partition key (time range based) too.  partition job detach/drop old partition and add/attach new partition each week.  
  when add/attach new partition , with default partition to verify that it contains no records which should be located in the partition being attached,  it will full scan or use partition key(part of primary key) scan instead ?  primary key (columa, partitionkey). 

Thanks,

James

James Pang <jamespang886@gmail.com> 於 2025年5月15日週四 下午9:32寫道:
thanks, we are checking  partition   maintain jobs ,that hold access exclusive lock.

Tom Lane <tgl@sss.pgh.pa.us> 於 2025年5月15日週四 下午9:24寫道:
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Thu, 2025-05-15 at 16:27 +0800, James Pang wrote:
>> why inserts into partition table cause "relation lock" ?

> Something else does; use the pg_blocking_pids() function with the process ID of
> a blocked backend to find out who is holding the lock.

More specifically: the inserts are only trying to get a shared lock.
If they are blocked, it's because some other operation is already
holding an exclusive lock on the table and is not letting go.
Look for uncommitted DDL changes.

More details about that at [1].

                        regards, tom lane

[1] https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-TABLES


pgsql-performance by date:

Previous
From: James Pang
Date:
Subject: Re: a lot of session wait on lock relation