Forum: help

Monitor Forum | Start New Thread Start New Thread
RE: CommandTimeout still broken in 2.0.8 [ reply ]
By: David Leaver on 2010-02-19 01:33
Yep that fixes it.


RE: CommandTimeout still broken in 2.0.8 [ reply ]
By: Francisco Figueiredo jr. on 2010-02-16 01:40

Hi, David.

Good catch!

I don't think internal NpgsqlCommand really need to not use the setting already done by user. So, for now it is removed. Please, give it a try and let me know if it works for you. I run your test here and it worked ok with the fix.

Thanks for feedback.

CommandTimeout still broken in 2.0.8 [ reply ]
By: David Leaver on 2010-02-14 23:02
Related Post:

I've been trying to upgrade some code from npgsql 1.0 to 2.0.
There are some quite long running SQL statements in the codebase, and it appears that CommandTimeout isn't being respected in all cases any more.

I've been debugging the issue and I think I've tracked it down:

NpgsqlConnector.CheckParameter gets called with 'escape_string_warning' (From UseConformantStrings, CheckStringConformanceRequirements), this sets _mediator.CommandTimeout to 20 (default for internal commands).
Once this is complete _mediator.CommandTimeout stays set to 20 rather than getting set back to the user defined NpgsqlCommand.CommandTimeout.

This causes the users SQL gets executed with the incorrect timeout set.
This doesn't happen if there are no parameters set as then CheckParameter doesn't get called to check 'escape_string_warning'.

Minimal example:

comm.CommandTimeout = 40; //Can be set in the command string, doesn't work either way
comm.CommandText = "SELECT pg_sleep(:time)";
comm.Parameters.Add("time", NpgsqlDbType.Double).Value = 30;

This can be fixed by changing NpgsqlConnector.CheckParameter to remember _mediator.CommandTimeout and re-setting it in a finally block. I'm not sure if this would be the best way however.

Could one of the Developers have a look and put in a fix please.

Powered By FusionForge