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