Get the modification time of a config file with a higher precision to fix cases when it's not reloaded after modification/replacement

[ilya071294]

The fix is needed to avoid potential problems in Firebird QA.

[aafemt]

Wouldn't it be better to make Windows version of getTime to return timespec and unify the rest of code?

Also it is simpler to use GetFileAttributesEx than FindFirstFile.

[ilya071294]

Wouldn't it be better to make Windows version of getTime to return timespec and unify the rest of code?

I can do that if conversion to timespec on every checkLoadConfig call is appropriate. @AlexPeshkoff What do you think?

Also it is simpler to use GetFileAttributesEx than FindFirstFile.

Done.

[aafemt]

I can do that if conversion to timespec on every checkLoadConfig call is appropriate.

IIRC this "conversion" is a couple of multiplication.

[dyemanov]

@AlexPeshkoff do you have any objections to this change?

[AlexPeshkoff]

Do something like this: namespace Firebird { class PreciseTime { public: PreciseTime() : high(0), low(0) {} #ifdef WIN_NT PreciseTime(//Windows specific ctor #else PreciseTime(//Posix specific ctor #endif

operator=(const PreciseTime&) = default;

private: time_t high; unsigned low; }; } // namespace

Next: Firebird::PreciseTime ConfigCache::File::getTime();

And return PreciseTime from that function - code around remains as clear as it was before.

[ilya071294]

I think it should be ported to FB3/4/5. Any objections?

[dyemanov]

I think it should be ported to FB3/4/5. Any objections?

I don't mind.

[pavel-zotov]

How to implement test for this ticket ? Does some API function or context variable [will] exist for checking config LUPD time ?

[ilya071294]

How to implement test for this ticket ? Does some API function or context variable [will] exist for checking config LUPD time ?

At the moment, the only way to test it is to replace some *.conf, see the effect, and then do it one more time in less than 1 second. I believe such specific test is not necessary. Anyway, this fix will be practically tested by running other tests with *.conf replacement.

[pavel-zotov]

An issue exists related to snapshots with dates before fix: in some cases engine can detect changes in the databases.conf even if time between connections much less than 1 s (~200...250 ms). Sent logs to Dmitry and Anton Zuev (RedBase).

[ilya071294]

An issue exists related to snapshots with dates before fix: in some cases engine can detect changes in the databases.conf even if time between connections much less than 1 s (~200...250 ms). Sent logs to Dmitry and Anton Zuev (RedBase).

I guess it can really happen because it depends on the exact moment when the 1-st connection is created. For example, it may be created just before the time changes to the next second. In this case changes in databases.conf will be detected by the 2-nd connection with a high probability.