For TKU September 2020 Extended Discovery pattern was updated. Database Schema node type and Database Table node type were updated to contain DB Server type. (DRDC1-14748)
Extended Discovery pattern which allows to model Database Detail Nodes being managed by the PostgreSQL Server is available for this product.
From TKU November 2017 onwards pattern will also discover Infobright Enterprise Edition. For more information, please visit Infobright Product Page .
Starting from TKU October 2018 modeling of SI key attribute has changed. Now SI key contains pg_data_path value.
Starting from TKU November 2018 PostgreSQL Database Server SI name attribute will contain bind_address and port values to be more unique.
PostgreSQL is a powerful, open source relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It runs on all major operating systems, including Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), and Windows. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL92 and SQL99 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation.
|Product Component||OS Type||Versioning||Pattern Depth|
|DatabaseServer||UNIX||Active (command), File, Path, Package||Instance-based or grouped on command-line args (data dependent)|
|Windows||WMI Query, Active (command), File, Path, Package|
The current pattern identifies an instance of PostgreSQL Server running on both Unix/Linux and Microsoft Windows platforms.
The following components/processes are identified using the combination of pattern definitions and simple identity mappings.
|PostgreSQL Database Server||regex '\bpostmaster$'|
|EnterpriseDB Postgres Advanced Server||regex '\bedb\-postmaster$'|
|PostgreSQL Database Server Control process||regex '(?i)\bpg_ctl\.exe$'|
|PostgreSQL Database Server||regex '\bpostgres:$'|
|EnterpriseDB Postgres Advanced Server||regex '\bedb\-postgres$'|
|PostgreSQL Database Server||regex '(?i)\bpostgres\.exe$'|
|PostgreSQL Scheduling Agent||regex '(?i)\bpagent\.exe$'|
|Postgres Enterprise Manager||regex '(?i)\bpem\.exe$'|
Version information for the product is currently collected using one of three possible methods. We execute the methods in order based on their accuracy, depth and reliability. Once a result is obtained, the method lower in precedence is not attempted. In order of precedence the methods are
On the Windows platform only, the pattern attempts to obtain version information by executing the following WMI query against the root\CIMV2 namespace:
We have been able to identify one method to actively version this product. It provides a good level of reliability on both platforms and does not require special permissions.
The first step for active versioning is to determine whether the path of the trigger process is an absolute path as only in that case will active versioning be attempted.
This is performed as follows:
The Unix specific version command is running postmaster command with the full path to it and "--version" parameter.
The Windows specific version command is running pg_ctl.exe command with the full path to it and "--version" parameter.
|Executed Command:||<abs_path_to_binary>/postmaster --version||Unix|
|Executed Command:||<abs_path_to_binary>\pg_ctl.exe --version||Windows|
The output is parsed using the following regular expression:
If we are unable to fetch the version from a previous versioning method we will attempt to read the PG_VERSION file in the <postgres_data_path> folder and parse its contents against the following regular expression:
If we are unable to fetch the version from a previous versioning method we will attempt to parse the process's command line to see if we can identify any installation version from path using the following regular expression:
This approach usually returns a version if path was not altered much during installation
If the pattern is unable to extract the version from a previous versioning method then it will attempt to query the package management system to obtain the product version.
The pattern supplies the package query with a set of regular expressions to be checked for.
|(?i)^Postgres Plus Advanced Server||Windows|
This usually returns a version if PostgreSQL was installed from package on Windows or Unix.
This attribute is first tried to be extracted from postgresql.conf file from "listen_addresses =" section.
If first approach failed or if listen_addresses is assigned to localhost or IP 127.0.0.1, then pattern tries to find target value by means of traverse to NetworkConnectionList on Discovery appliance. Port value is used for such traverse.
Following its startup, the PostgreSQL server will launch a number of worker processes which handle the various DB server functions
The pattern triggers on postmaster or pg_ctl process (or edb-postmaster or edb-postgres in the case of an EnterpriseDB installation) since these processes shows that PostgreSQL is running.
The pattern then attempts to determine pg_data_path and the port the DB server is listening on and uses all these as part of the SI key If the key cannot be obtained, the pattern will create a grouped SI using the trigger process command-line arguments.
Finally, the pattern creates association links with processes related to the trigger process (child processes started by the main process)
The current Windows pattern trigger assumes that PostgreSQL is running as a service (expected in production environment)
A separate pattern has been created to query the PostgreSQL Server in order to obtain database list and (optionally) database table details. For more information about this pattern, please refer to the relevant page.
Subject Matter Expert input will be welcome on any other potential approaches not discussed to improving product versioning coverage of PostgreSQL RDBMS especially with regard to EnterpriseDB installations.
Testing to ensure the processes related to PostgreSQL Database Server have been correctly identified and that the product can be versioned has been performed using Discovery record data as well as live discovery of hosts running Solaris, Linux and Windows operating systems.
There are no known open issues with this pattern.