| From: | Christophe Pettus <xof(at)thebuild(dot)com> | 
|---|---|
| To: | Costa Alexoglou <costa(at)dbtune(dot)com> | 
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: Vacuum full connection exhaustion | 
| Date: | 2024-08-08 14:11:21 | 
| Message-ID: | 66D17234-043D-457E-8607-5126B4FBC3DD@thebuild.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anthony Apollis | 2024-08-08 16:35:00 | Destination Table - Condition Amount 0 | 
| Previous Message | Francisco Olarte | 2024-08-08 11:43:54 | Re: Vacuum full connection exhaustion |