public inbox for [email protected]
help / color / mirror / Atom feedFrom: Christophe Pettus <[email protected]>
To: Costa Alexoglou <[email protected]>
Cc: [email protected]
Subject: Re: Vacuum full connection exhaustion
Date: Thu, 8 Aug 2024 07:11:21 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJ+5Ff6WtFCzamrRZqN3u3htvkGcmob7VaYWYBd+sRx6jKpHuA@mail.gmail.com>
References: <CAJ+5Ff6WtFCzamrRZqN3u3htvkGcmob7VaYWYBd+sRx6jKpHuA@mail.gmail.com>
> On Aug 7, 2024, at 10:34, Costa Alexoglou <[email protected]> wrote:
>
> Hey folks,
>
> I noticed something weird, and not sure if this is the expected behaviour or not in PostgreSQL.
>
> 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.
>
> 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.
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Vacuum full connection exhaustion
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox