-
-
Notifications
You must be signed in to change notification settings - Fork 260
Get the modification time of a config file with a higher precision to fix cases when it's not reloaded after modification/replacement #8553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… fix cases when it's not reloaded after modification/replacement The fix is needed to avoid potential problems in Firebird QA.
Wouldn't it be better to make Windows version of Also it is simpler to use |
I can do that if conversion to
Done. |
IIRC this "conversion" is a couple of multiplication. |
@AlexPeshkoff do you have any objections to this change? |
Do something like this: operator=(const PreciseTime&) = default; private: Next: And return PreciseTime from that function - code around remains as clear as it was before. |
I think it should be ported to FB3/4/5. Any objections? |
I don't mind. |
… a higher precision to fix cases when it's not reloaded after modification/replacement (#8553)
… a higher precision to fix cases when it's not reloaded after modification/replacement (#8553)
… a higher precision to fix cases when it's not reloaded after modification/replacement (#8553)
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. |
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). |
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. |
The fix is needed to avoid potential problems in Firebird QA.