From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Vacuum full connection exhaustion |
Date: | 2024-08-09 04:15:33 |
Message-ID: | CANzqJaDZDLnYhPEds8jMf4ArEG1MOVtiPr7g0GvPMiEpjrNqiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Aug 8, 2024 at 10:12 AM Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
>
> > On Aug 7, 2024, at 10:34, Costa Alexoglou <costa(at)dbtune(dot)com> 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.
>
>
"I see a lock, so let's cause another one!" That's crazy.
--
Death to America, and butter sauce.
Iraq lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2024-08-09 04:17:51 | Re: Vacuum full connection exhaustion |
Previous Message | David Rowley | 2024-08-08 23:02:19 | Re: Vacuum full connection exhaustion |