Skip to content
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

Closed
firebird-issue-importer opened this issue Dec 23, 2011 · 19 comments
Closed

Comments

@firebird-issue-importer

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

Commented by: @dyemanov

Why do you need to know the build number, architecture and port number?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.
port number may be useful to know only inside application - just to get it more quickly than open firebird.conf on server console

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

Commented by: @pavel-zotov

>"show version" in ISQL should report the build number.
this is not programmatical way!
i mean that an application must 'see' such info via calls rather than isql console

>The server arch term is getting outdated with FB3
currently there is no FB 3.x. even in beta.
most people works in 2.0 / 2.1 / 2.5.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 23, 2011

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 29, 2011

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.
BTW, MSSQL already have this feature, don't know about others

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 9, 2016

Modified by: @dyemanov

Link: This issue is duplicated by CORE4496 [ CORE4496 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 9, 2016

Modified by: @dyemanov

Fix 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 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 9, 2016

Modified by: @dyemanov

Fix Version: 4.0 Beta 1 [ 10750 ]

Fix Version: 4.0 Alpha 1 [ 10731 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 22, 2019

Modified by: @dyemanov

Fix Version: 4.0 Beta 1 [ 10750 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 18, 2020

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ] => Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 11, 2020

Commented by: @hvlad

It will be nice to have ability to query configuration settings using SQL language.
Configuration here is contents of firebird.conf, databases.conf and settings passed via DPB when applicable.

Proposed solution is to introduce new virtual table to expose settings values.
Table defined as

CREATE TABLE RDB$CONFIG
(
RDB$CONFIG_ID INTEGER NOT NULL,
RDB$CONFIG_NAME VARCHAR(63) CHARACTER SET ASCII NOT NULL,
RDB$CONFIG_VALUE VARCHAR(255) CHARACTER SET UTF8,
RDB$CONFIG_DEFAULT VARCHAR(255) CHARACTER SET UTF8,
RDB$CONFIG_IS_SET BOOLEAN NOT NULL,
RDB$CONFIG_SOURCE VARCHAR(255) CHARACTER SET UTF8
);

where
- RDB$CONFIG_ID
unique row identifier, no special meaning

- RDB$CONFIG_NAME
setting name, such as "DefaultDbCachePages", "TempCacheLimit" and so on

- RDB$CONFIG_VALUE
actual value of setting, could be set in configuration and, if necessary, "fixed" by the engine (in case of wrong value)

- RDB$CONFIG_DEFAULT
default value of setting, fixed at Firebird code

- RDB$CONFIG_IS_SET
TRUE, if value was set by user

- RDB$CONFIG_SOURCE
name of configuration file where setting was set, relative to the firebird root folder, for example: "firebird.conf", "databases.conf"
or special value "DPB" if setting was set in DPB,
If setting value was not set, this field contains NULL

Table RDB$CONFIG is populated from in-memory structures when required and instance is kept at SQL query level.
For security reasons access is allowed to the SYSDBA/OWNER only (it could be changed before release).
Non-privileged user see empty content, no error is raised (also could be changed).

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 11, 2020

Modified by: @hvlad

Link: This issue is duplicated by CORE6444 [ CORE6444 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 13, 2020

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 RC 1 [ 10930 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 20, 2021

Modified by: @dyemanov

issuetype: Improvement [ 4 ] => New Feature [ 2 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants