Use NpgsqlConnection when checking if database exists.

[marcusber]

The NpgsqlRelationalConnection gets an implicit reference to the DbContext from the original connection (through Dependencies). That could tamper with the original DbContext's ServiceProvider when adding a connection to completly different pool. Also, the test only wants a connection to the database which NpgsqlConnection could provide.

CreateAdminConnection suffers from the same problem. That together with this may be the root of the problem of #3560.

[marcusber]

CreateAdminConnection is not used in the migration, so that is not the problem in the issue. The usage may be problematic though.

[roji]

That could tamper with the original DbContext's ServiceProvider when adding a connection to completly different pool.

There is no relationship between the service provider and connection pooling - the former is within EF, whereas the latter is managed at the lower-level ADO.NET layer which has nothing to do with EF.

What's the exact motivation behind this change? Are you seeing an actual issue or bug that this is meant to fix?

[marcusber]

Well, indirect there is a relationship between the Pool and the DbContext's ServiceProvider. It is returned to the pool by disposing the NpgsqlRelationalConnection registered in the DbContext's provider.

I was affraid that something was added to the original DbContext's ServiceProvider from a completely different data source. However this doesn't seem related to the problem I'm seeing.

I'll do some further investigations and try to describe the problem further. Basically what I'm after is to figure out why I see a connection leak when doing a migration. I don't have the same problem with the SqlServer-version, so it is likely something related to efcore.pg. Closing this for now.