Re: Lock timeout in commit

From: Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Lock timeout in commit
Date: 2025-07-10 20:32:45
Message-ID: CAKE1AiYMY2wk5BhACRvFhyNoKhJ9thhfaQ07DnFO-Ogg0oeENw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 11 Jul 2025 at 01:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> I think all you could do is monitor the pg_locks view and hope to
> catch the process in "waiting" state before it fails.
>
> It occurs to me to wonder though if we couldn't provide more
> context in the error about what lock is being waited for.
>
> Thanks Tom !!

The application is an API server so we intentionally set the lock timeout
to a very short interval (5 ms). Having locking context would be great.

Other than deferred FK constraints, what other locking actions are deferred
to commit time?

Cheers,

Steve

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-07-11 02:09:41 RE: error “server process was terminated by signal 11: Segmentation fault” running pg_create_logical_replication_slot using pgoutput plugin
Previous Message Greg Hennessy 2025-07-10 19:39:12 optimizing number of workers