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
Add actual configuration settings to the monitoring tables [CORE3708] #4056
Comments
Commented by: @dyemanov Why do you need to know the build number, architecture and port number? |
Commented by: @dyemanov Also, it makes very little sense to return the setting from firebird.conf, as overrides are possible at other levels. I'd rather think about returning the actual values used by the engine at runtime. |
Commented by: @pavel-zotov when i run some tests inside isql i often forget which exactly server version (build and architecture) is in test now. |
Commented by: @dyemanov "show version" in ISQL should report the build number. The server arch term is getting outdated with FB3, something different should be returned instead. As for the the server port number, it's currently unknown inside the engine, thus hardly possible to return. Also, imagine two CS instances listening on different TCP ports but sharing the same database. So the server port number should be a connection property, not the server one. |
Commented by: @pavel-zotov ps. also, as admin i want to restrict access to /opt/firebird folder for any common developer but let him obtain info about some configuration parameters. |
Commented by: @pavel-zotov >"show version" in ISQL should report the build number. >The server arch term is getting outdated with FB3 |
Commented by: @dyemanov You were speaking about the user's way ("I often forgot which version is connected to"), not the programmatical way! And it's useless information for the application, because the feature set is uniquely identified by <major ver>.<minor ver>.<sub ver>. Build number could be actual for some intermediate (snapshot) build but relying on that in the application is terribly wrong. FB 2.x are unlikely to get any new features, especially the ones that won't make any sense in the subsequent versions. |
Commented by: @dyemanov Providing the "common developer" access to the configuration sounds like a security risk. It's also seems useless in general, e.g. if the global config says "cache size = 75", the database-specific config says "cache size = 1000" and the application overrides this with "cache size = 10000" at runtime. |
Commented by: Sean Leyne (seanleyne) Pavel why do you open tracker cases only to have them, in most cases, be rejected. Please stop this usage pattern. The project Support, Dev and Architecture mailing lists are the correct forum to present your ideas. These are where ideas can be reviewed and discussed with the widest audience. Then, if the issue has not been "rejected", you can open a tracker case with the details which have been agreed to. |
Commented by: @hvlad Dmitry, > I'd rather think about returning the actual values used by the engine at runtime. You've got my voice :) I think this is must have feature, especially in FB3 where configuration will be more complex than now. |
Modified by: @dyemanovFix Version: 4.0 Alpha 1 [ 10731 ] assignee: Dmitry Yemanov [ dimitr ] summary: Add context vaiables about current FB settings (create new MON$SERVER table ?) => Add actual configuration settings to the monitoring tables Version: 2.5.2 [ 10450 ] => |
Modified by: @dyemanovFix Version: 4.0 Beta 1 [ 10750 ] => |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] => Vlad Khorsun [ hvlad ] |
Commented by: @hvlad It will be nice to have ability to query configuration settings using SQL language. Proposed solution is to introduce new virtual table to expose settings values. CREATE TABLE RDB$CONFIG where - RDB$CONFIG_NAME - RDB$CONFIG_VALUE - RDB$CONFIG_DEFAULT - RDB$CONFIG_IS_SET - RDB$CONFIG_SOURCE Table RDB$CONFIG is populated from in-memory structures when required and instance is kept at SQL query level. |
Modified by: @hvladstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 RC 1 [ 10930 ] |
Modified by: @dyemanovissuetype: Improvement [ 4 ] => New Feature [ 2 ] |
Submitted by: @pavel-zotov
Is duplicated by CORE4496
Is duplicated by CORE6444
Votes: 1
An application can not obtain server build (like `WI-V2.5.2.26390`), server architecture (classic / SC / SS / embed) and port number (in case of TCP using),
via context variables.
Can these data be added to SYSTEM namespace (for using with RDB$GET_CONTEXT() function) or just new built-in variables like current_connection et al ?
Encompassing question: is it possible to get all the settings from firebird.conf via context variables or new MON$-table (e.g. 'MON$SERVER_SETTINGS') ?
// especially interesting for: TempDirectories, AuditTraceConfigFile, DefaultDbCachePages, FileSystemCacheThreshold and MaxUnflushed* parameters
The text was updated successfully, but these errors were encountered: