Npgsql is the .NET data provider for Postgresql. It allows any program developed for .NET framework to access a Postgresql database server. It is implemented in 100% C# code. Postgresql versions since 10.0 are officially supported, others may work.
i have reported it, do have a look at it
thats my problem
the codes below ExecuteReaderAsync() does not run. I tried debugging too, the execution goes into this function but never comes out
Npgsql definitely does not hang if you attempt to execute bad SQL
I got a question, how should I log the queries being run on c# to Postgres logging? I am not sure how to achieve this task. I tried with the documentation but it was quiet hard for me to understand.
Have you tried just doing this? https://www.npgsql.org/doc/diagnostics/logging.html#consoleloggingprovider
Is mapping an enum type supported with
DbDataSource (via NpgsqlDataSourceBuilder) when using EF Core? Everything works fine if I continue to use the global type mapper, but if I map the enum using the builder I get exceptions about types/operators not existing at first query
@pinkfloydx33 saw your issue (#2557), this absolutely should be supported. I'll look at it later today.
Creating many
DbDataSource (i.e. per-context) appears to be a bad idea. I've got test classes each using a dedicated postgres container and running in parallel. I was creating a new data source for every new context (so per test). All's well if I run without test-class parallelization, but things go haywire otherwise: random timeouts, "error reading from stream" and EnsureCreated throwing because the db already exists. I fixed it by creating one data source per test fixture/container and now everything is smooth sailing. Did I miss that called out somewhere?
Hello, according to https://www.npgsql.org/efcore/modeling/generated-properties.html#guiduuid-generation Guid objects which are mapped to the uuid type in Postgres are automatically generated clientside by the provider. I am not having any success with this, the field is not autopopulated by Npgsql. When ValueGeneratedOnAdd() is added to my entity configuration, the value sent to the database is NULL, which results in a non-null constraint violation. When ValueGeneratedOnAdd() is removed from my configuration, it does 1 insert of the empty 00000000-0000-0000-0000-000000000000 GUID, which of course is not correct. How can I get Npgsql to clientside generate these Guids correctly? Thanks!
@AlbertoPa Interesting! Do you create yours as part of the SaveChanges(Async)? That's where I generate my Created and Updated values, and where I intend to put Guid generation if I can't get this working. I would like to push this one further though, might create a GitHub issue depending on the response here, as the documentation is either wrong, or lacking clarity as to methodology
So when the model is constructed, the GUID isn't null.
@pinkfloydx33 each DbDataSource corresponds to a connection pool, so creating one per context amounts to disabilng pooling; that's definitely not how DbDataSource is usually supposed to be used. I'm not sure why you'd get random timeouts or "error reading from stream" errors, unless establishing a new physical connection each time (since pooling is off) itself causes the issue. EnsureCreated throwing because the DB already exists likely isn't related to this - first, it's not supposed to throw at all if the database already exists (hence the "Ensure" in the name). Looking at the basic usage docs (https://www.npgsql.org/doc/basic-usage.html#data-source), it seems pretty clear to me that the same data source is supposed to be used to create multiple connections - did you understand it differently?
I have replied and I am about to test your solution
@roji I guess I understood it correctly, but it didn't occur to me there'd be issues/exceptions if I did use multiples. Keep in mind this was during tests so not during normal usage and I resolved it by creating one per server/database (container). This makes me wonder what happens if someone creates the data source (entire builder or built product) completely within the AddDbContext callback, rather than outside of it as that would be tantamount to the same thing (at least against a single server) and essentially what I was doing in tests. I can pretty reliably recreate the EnsureCreated issue if I revert my single-data-source-fix. I initially solved it by adding a try/catch similar to the ones you already use (but with a different exception filter) which as you said makes no sense given how it's supposed to work. But again, no longer a problem using one datasource per endpoint
There indeed shouldn't be a problem with creating multiple data sources for the same connection string or database (though there's typically no good reason to do so) - it's very similar to turning off pooling. Creating the data source inside OnConfiguring would lead to this, since OnConfiguring is executed for each context instance. But AddDbContext should cause the callback to only run once, which should have the better result. You may be interested in npgsql/efcore.pg#2542 and dotnet/efcore#29489.
Hi Guys, I have a slight left field question. We are using Npgsql + EF to talk to "good" ole Redshift. However, we have started encountering:
Npgsql.PostgresException: 57P01: terminating connection due to session timeout errors. The request itself is pretty straight forward, no joins or particular nasty expressions as part of query. The thing is is I repeat the query it works....so in short, the client makes a call to the route, the error above is thrown, the client then re-invokes the route, then it works -_- The failure is always the first invocation. It is a tad hard to trigger to locally as this only happens in environments that we cannot test against, and cannot replicate it locally. Does anyone have any ideas what\where I could look to see what might be causing this behaviour....note I don't think it is directly an issue in npgsql...just reaching in case someone might be in the know.
Hi, i have a question. I'm using efcore 7, dotnet 7, NpgsqlEntityFrameworkCore.Postgresql 7.0.0
I have a simple test application, generating an API response with data from postgresql.
When I make the first request to this API, i get the correct data from my database. But after the first response (i.e. when i refresh the API page in my browser), i get this error (first 3 lines):
System.InvalidOperationException: The ConnectionString property has not been initialized.
at Npgsql.NpgsqlConnection.Open(Boolean async, CancellationToken cancellationToken)
at Npgsql.NpgsqlConnection.OpenAsync(CancellationToken cancellationToken)This is the AddDbContext call in my program.cs:
builder.Services.AddDbContext<PriceListDbContext>(options =>
{
var dbDataSource = new NpgsqlDataSourceBuilder(builder.Configuration.GetConnectionString("PriceListDB"));
Console.WriteLine(builder.Configuration.GetConnectionString("PriceListDB"));
dbDataSource.MapEnum<PackagingAmountType>();
options.UseNpgsql(dbDataSource.Build());
}Any ideas what might be going on here?
The code looks ok - I'm assuming you've already checked that the connection string from configuration isn't null... If so, can you open an issue on https://github.com/npgsql/efcore.pg and submit a minimal repro so I can investigate?
I'm using postgresql 15 in docker btw
Given iteration: pooledfactory.createcontext, add entity, savechanges async... Average insert takes around 0.3 ms. Add await Task.Delay(100) in each iteration and measure only savechanges... It averages 5ms per insert. Connection pooling is enabled... Why would delay change performance from 0.3ms to 5ms... This benchmark was done using benchmark.net. Using sqlite, timings are always 2ms... Why are we experiencing such behaviour?
NpgsqlDataSourceBuilder.MapEnum<> does not replace NpgsqlConnection.GlobalTypeMapper.MapEnum<>, am I correct? Even though GlobalTM is marked as obsolete? Because without doing MapEnum on GTM, i get the error that npgsql is shipping integers to the db, when it expected an enum type.
Or: I can't get the sourceBuilder.MapEnum to work.