Gitlab 14.2.1, issue with postgres

Hello, forgive me for my bad english.

I’ve upgraded my gitlab instance from 14.1.0-ee to 14.2.1-ee, and since this upgrade randomly the users have some errors (500, 404, etc). After investigation, it seems that all connections to my separate postgres dataase are full:

FATAL: remaining connection slots are reserved for non-replication superuser connections

It seems that the 14.2.1 version make a lot more connections to postgres or do not release unused connections ?

Actually I have upated postgres max_connections to 200 (100 to 200). But I really don’t knox if it is a real solution.

Gtlab 14.2.1-ee on docker
Postgres 12.3 on docker

Thanks for your help.

1 Like

I am seeing the same, this seems to be caused by sidekiq. I see many connections with an application name of:

sidekiq 5.2.9 queues:authorize...export_deletion [0 of 50 busy] 

did you open a ticket?

No. I don’t have any license on this instance. Is it possible to fill a bug or an issue on the public github repo ?

Yes, something certainly changed. This will also affect free licenses; filing on GitLab.org / GitLab · GitLab should be fine. Make sure to include as many details as possible like the output of SELECT * FROM pg_stat_activity where usename='gitlab'; and sanitize potential sensitive queries.

Ok issue is created: Gitlab 14.2.1, issue with postgres (#339715) · Issues · GitLab.org / GitLab · GitLab :slight_smile:

1 Like

For anyone looking here, looks the workaround is to set the max_connections flag on your PostgreSQL server to 200 or higher.

1 Like

With omnibus installation, in the /etc/gitlab/gitlab.rb:

# postgresql['max_connections'] = 200

mine is commented and thus is using whatever defaults Gitlab sets. Perhaps the Gitlab docker image was limited to 100 at one point, hence requiring the change. Or perhaps earlier installations like 3 years ago used less connections maybe and after upgrading required increasing this value?

1 Like