Re: Vacuum full connection exhaustion

Поиск
Список
Период
Сортировка
Искать
От
Christophe Pettus
Тема
Re: Vacuum full connection exhaustion
Дата
Msg-id
66D17234-043D-457E-8607-5126B4FBC3DD@thebuild.com
Ответ на
Список
Дерево обсуждения
Vacuum full connection exhaustion Costa Alexoglou <costa@dbtune.com>
Re: Vacuum full connection exhaustion Christophe Pettus <xof@thebuild.com>
Re: Vacuum full connection exhaustion David Rowley <dgrowleyml@gmail.com>
Re: Vacuum full connection exhaustion Costa Alexoglou <costa@dbtune.com>
Re: Vacuum full connection exhaustion Ron Johnson <ronljohnsonjr@gmail.com>
Re: Vacuum full connection exhaustion Christophe Pettus <xof@thebuild.com>
Re: Vacuum full connection exhaustion Francisco Olarte <folarte@peoplecall.com>
Re: Vacuum full connection exhaustion Ron Johnson <ronljohnsonjr@gmail.com>


> On Aug 7, 2024, at 10:34, Costa Alexoglou  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.

В списке pgsql-general по дате отправления
От: Francisco Olarte
Дата:
От: Anthony Apollis
Дата:
FAQ