CODEWITHSUNDEEP
.netdatabase-connectionamazon-rdsfatal-error
temo mikava
temo mikava

Reputation: 11

AWS PostgreSQL "FATAL: remaining connection slots are reserved for non-replication superuser connections" After Upgrading .NET Version

I'm encountering an issue with my application hosted on AWS after upgrading from .NET 6.0 to .NET 8.0. My application is running in a Docker container.

After the upgrade, I started receiving the following error when trying to connect to my AWS PostgreSQL database: FATAL: remaining connection slots are reserved for non-replication superuser connections Environment: AWS RDS PostgreSQL, Docker container (production) Changes Made: The only changes I made were: Upgraded from .NET 6.0 to .NET 8.0. Updated the Dockerfile to reflect the new .NET version. I have not changed anything else in the application code or the database connection settings. The application was running smoothly before the upgrade.

Tested the application locally with the new configuration but didn’t experience the same connection issue.

Why is this connection issue occurring with only the changes I made to upgrade the .NET version? Is there something in .NET 8.0 that could affect how connections are managed?

Any insights or suggestions would be greatly appreciated!

Upvotes: 0

Views: 55

Answers (1)

temo mikava
temo mikava

Reputation: 11

This issue arose because I was creating a new NpgsqlDataSource instance in each DbContext, leading to excessive connections to my AWS PostgreSQL database.

Initially, my configuration looked like this:

builder.Services.AddDbContext<MasterDbContext>(options =>

{

var dataSource = new NpgsqlDataSourceBuilder(    builder.Configuration.GetConnectionString(nameof(MasterDbContext))! ).EnableDynamicJson().Build();

options.UseNpgsql(dataSource);

});

builder.Services.AddDbContext<SlaveDbContext>(options =>

{

var dataSource = new NpgsqlDataSourceBuilder(

builder.Configuration.GetConnectionString(nameof(SlaveDbContext))!).EnableDynamicJson().Build();

options.UseNpgsql(dataSource);

});

With this setup, every instantiation of DbContext created a new NpgsqlDataSource, quickly exhausting the available connection slots.

To address this issue while enabling dynamic JSON support, I switched to using keyed singletons for my NpgsqlDataSource instances. Here’s how I implemented it:

I registered NpgsqlDataSource as keyed singletons to ensure that only one instance is created:

builder.Services.AddKeyedSingleton<NpgsqlDataSource>("Master", serviceProvider =>

{

var connectionString = builder.Configuration.GetConnectionString(nameof(MasterDbContext));

return new NpgsqlDataSourceBuilder(connectionString)

.EnableDynamicJson()

.Build();

});

builder.Services.AddKeyedSingleton<NpgsqlDataSource>("Slave", serviceProvider =>

{

var connectionString = builder.Configuration.GetConnectionString(nameof(SlaveDbContext));

return new NpgsqlDataSourceBuilder(connectionString)

.EnableDynamicJson()

.Build();

});

I updated the DbContext registrations to utilize these keyed services:

builder.Services.AddDbContext<MasterDbContext>((serviceProvider, options) =>

{

var dataSource = serviceProvider.GetRequiredKeyedService<NpgsqlDataSource>("Master");

options.UseNpgsql(dataSource);

});

builder.Services.AddDbContext<SlaveDbContext>((serviceProvider, options) =>

{

var dataSource = serviceProvider.GetRequiredKeyedService<NpgsqlDataSource>("Slave");

options.UseNpgsql(dataSource);

});

This approach allowed me to enable dynamic JSON support on Npgsql while managing database connections more effectively, resolving the errors that arose after the .NET upgrade.

Upvotes: 1

Related Questions