Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: Vacuum full connection exhaustion
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <CAJ+5Ff6WtFCzamrRZqN3u3htvkGcmob7VaYWYBd+sRx6jKpHuA@mail.gmail.com>
Date: Thu, 8 Aug 2024 07:11:21 -0700
Cc: pgsql-general@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <66D17234-043D-457E-8607-5126B4FBC3DD@thebuild.com>
References: <CAJ+5Ff6WtFCzamrRZqN3u3htvkGcmob7VaYWYBd+sRx6jKpHuA@mail.gmail.com>
To: Costa Alexoglou <costa@dbtune.com>
Archived-At: <https://www.postgresql.org/message-id/66D17234-043D-457E-8607-5126B4FBC3DD%40thebuild.com>
Precedence: bulk


> On Aug 7, 2024, at 10:34, Costa Alexoglou <costa@dbtune.com> wrote:
>=20
> Hey folks,
>=20
> I noticed something weird, and not sure if this is the expected =
behaviour or not in PostgreSQL.
>=20
> So I am running Benchbase (a benchmark framework) with 50 terminals =
(50 concurrent connections).
> There are 2-3 additional connections, one for a postgres-exporter =
container for example.
>=20
> So far so good, and with a `max_connections` at 100 there is no =
problem. What happens is that if I execute manually `VACUUM FULL` the =
connections are exhausted.

VACUUM FULL takes an exclusive lock on the table that it is operating =
on.  It's possible that a connection becomes blocked on that exclusive =
lock waiting for the VACUUM FULL to finish, the application sees the =
connection stopped and fires up another one (this is common in =
container-based applications), that one blocks... until all of the =
connections are full of queries waiting on that VACUUM FULL.=