Product Description

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.

Known Versions

• 1.0
• 1.01
• 1.02
• 1.09
• 6.0
• 6.1
• 6.2
• 6.3
• 6.4
• 6.5
• 7.0
• 7.1
• 7.2
• 7.3
• 7.4
• 8.0
• 8.1
• 8.2
• 8.3
• 8.4
• 9.0
• 9.1
• 9.2
• 9.3
• 9.4
• 9.5
• 9.6

Software Pattern Summary

Platforms Supported by the Pattern

The current pattern identifies an instance of PostgreSQL Server running on both Unix/Linux and Microsoft Windows platforms.

Identification

Software Instance Triggers

Simple Identification Mappings

The following components/processes are identified using the combination of pattern definitions and simple identity mappings.

Versioning

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

WMI Versioning (Windows Only)

On the Windows platform only, the pattern attempts to obtain version information by executing the following WMI query against the root\CIMV2 namespace:

• SELECT Version FROM CIM_DataFile where Name='<trigger_process_cmd>'

Active Versioning - Command Execution

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.

Common Functionality

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:

Unix

• regular expression used to match against the trigger process command: '^/'

Windows

• regular expression used to match against the trigger process command: '^\w:'

Command Execution

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.

The output is parsed using the following regular expression:

File Versioning

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:

• (\d+(?:\.\d+)*)

Path Versioning

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

Package Versioning

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.

This usually returns a version if PostgreSQL was installed from package on Windows or Unix.

bind_address attribute

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.

Application Model Produced by Software Pattern

Product Architecture

Following its startup, the PostgreSQL server will launch a number of worker processes which handle the various DB server functions

Software Pattern Model

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)

Obtaining detailed PostgreSQL Database, Schema and Table information

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 Expertise

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

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.

Information Sources

Open Issues

There are no known open issues with this pattern.