From: | James Pang <jamespang886(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: a lot of session wait on lock relation |
Date: | 2025-05-15 13:32:38 |
Message-ID: | CAHgTRffkd2uUKxsRKvC3hU-Vje9S=JHxN134YkVN_WhYOw45-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
thanks, we are checking partition maintain jobs ,that hold access
exclusive lock.
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 於 2025年5月15日週四 下午9:24寫道:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | James Pang | 2025-05-15 13:43:17 | Re: a lot of session wait on lock relation |
Previous Message | Tom Lane | 2025-05-15 13:24:30 | Re: a lot of session wait on lock relation |