Document not blocking the thread after multiplexing execution

[vonzshik]

[Test]
public async Task GetDataTypeName_enum()
{
	var csb = new NpgsqlConnectionStringBuilder(ConnectionString)
	{
		MaxPoolSize = 1,
		Multiplexing = true
	};
	await using var conn = await OpenConnectionAsync(csb);
	await using var _ = await GetTempTypeName(conn, out var typeName);
	await conn.ExecuteNonQueryAsync($"CREATE TYPE {typeName} AS ENUM ('one')");
	conn.ReloadTypes();
	await using var cmd = new NpgsqlCommand($"SELECT 'one'::{typeName}", conn);
	await using var reader = await cmd.ExecuteReaderAsync(Behavior);
	await reader.ReadAsync();
	Assert.That(reader.GetDataTypeName(0), Is.EqualTo($"public.{typeName}"));
}

@roji @NinoFloris

[roji]

Design decision: it's illegal to call sync ReloadTypes() on a multiplexing connection/data source; this should throw. Introduce a ReloadTypesAsync().

Note: if intensive computation occurs after ExecuteNonQueryAsync above, the connection won't be returned to the pool until the next yield. The only way to mitigate that would be an extra dispatch (really bad perf), or switch the dispatch between ExecutionCompletion and ReaderCompleted; but this would regress perf for small resultsets (e.g. TechEmpower) since when awaiting on ReaderCompleted the callback wouldn't yet be registered.

[roji]

After discussing this again with @Brar and thinking about it, I'm not sure we should be doing anything here.

We know that for the multiplexing productization, we plan to make multiplexing work only through the data source command API (npgsql/npgsql#4496). At that point, open NpgsqlConnections by definition are always already bound to a connector, and so would never block on needing to get one. This means that only sync APIs on commands would need to throw when used on a multiplexing data source (as well as sync NpgsqlConnection.Open() and NpgsqlDataSource.Open(), of course).

Assuming the above is correct, we shouldn't start adding checks to throw from ReloadTypes or any other sync API, since those would no longer be necessary in 8.0. And we'd move this issue to 8.0 for making sure all command and connection open APIs have checks.

@NinoFloris @vonzshik does the above make sense or have I forgotten something?

[vonzshik]

I'm OK with not doing anything as long as we document at some point this caveat with multiplexing (that is, either avoid doing any long-running cpu-bound work after queries, or yield the thread by, for example, calling await Task.Yield().

[roji]

@vonzshik sure, though note that's orthogonal to whether we do anything in our own APIs (i.e. throw from sync ReloadTypes() when in multiplexing).

But it's true that in general, someone using multiplexing and blocking the thread right after execution would block returning the connection etc. We should note that in the multiplexing docs.

[roji]

Moving this to the docs repo.