Also reviewing if we really need SERIALIZED and could instead use READ
COMMITTED. Would that be likely to mitigate against this happening?
PostgreSQL can NOT go below READ COMMITTED in transaction isolation
levels. Read Committed is the default mode for all transactions in
PostgreSQL
https://ww
On Mon, Sep 8, 2025 at 12:04 PM Alec Cozens wrote:
> Looking at the postgresql code, the LW lock SerializableFinishedList
> appears to be acquired and then released, usually in the duration of a call
> to a procedure. Base on that (admittedly maybe faulty) view of the code, I
> am surprised to se
: Alec Cozens
Sent: 08 September 2025 11:28
To: Justin
Cc: pgsql-gene...@postgresql.org
Subject: RE: LWLock SerializableFinishedList
** This email is from an EXTERNAL sender **
Thanks Justin,
We’ll try the lock_timeout configuration. We originally discarded it’s use
because statement_timeout
erial": apparent wraparound
in the postgres logs. I’ve always ignored this as I believed it to be benign or
incorrectly reported.
Thanks for your help.
Regards,
Alec
From: Justin
Sent: 05 September 2025 19:00
To: Alec Cozens
Cc: pgsql-gene...@postgresql.org
Subject: Re: LWLock SerializableFi
On Fri, Sep 5, 2025 at 1:02 PM Alec Cozens wrote:
> Hi
>
>
>
> I’m having trouble with PostgreSQL 16.8 on Windows where for maybe days it
> all works perfectly until the number of active connections start
> increasing, until over say 10 minutes all 97 connections are active but
> seemingly waitin
Hi
I'm having trouble with PostgreSQL 16.8 on Windows where for maybe days it all
works perfectly until the number of active connections start increasing, until
over say 10 minutes all 97 connections are active but seemingly waiting on
LWLock on SerializableFinishedList. They will remain in thi
