Race condition in db_get_field_and_count()

So much for all our swearing about atomicity...

The fix seems reasonable. Since the record is locked, should also change dbGetField() to dbGet() and avoid unnecessary calls to dbScanLock().

I looked into that - for the more recent versions, definitely but in 3.14 dbGetField() does more than just lock and dbGet.

Then I shall limit myself to saying that dbChannelGetField() calls should be changed to dbChannelGet().

This is a ca_get(), so there is no db_field_log to store any posted data. For a monitor the fact that we unlock and re-lock the record between fetching the value and its attributes should only matter for strings, arrays, and the larger composite data types since nothing else should be able to modify the contents of our db_field_log object (I'm assuming that the monitor event has been pulled off the queue by this point so cached updates can't affect it any more). Thus for the smaller data types atomicity of monitors should always have been preserved.

Thanks for the discussion, I will apply this patch to 3.14. Has anyone already worked out what the correct changes will be for 3.15, since they are different? [Don't do so if you haven't already got them though].

I agree with Michael's latest comment that for 3.15 and later we should change dbChannel_get_count() to call dbChannelGet() instead, I'll make that adjustment as I merge the change up from 3.14.