Re: a lot of session wait on lock relation

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
>
>
>

In response to

Responses

Browse pgsql-performance by date

  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