Version Support for PostgreSQL extensions

[resyfer]

[resyfer]

Config

Considering each server may have their own version of an extension independent of others, I think the following syntax in YAML would do for this task:

version: ...
metrics:
  - queries:
    - query: "Query 1"
      version: 14 # Version For PostgreSQL
      extensions:
        - name: "extension1"
          version: 1.0
        - name: "extension2"
          version: 2.5
    - query: "Query 2"
      version: 16 # Version For PostgreSQL
      extensions:
        - name: "extension1"
          version: 1.5
        - name: "extension2"
          version: 4.5
      

Where for the following values of postgresql version, extension1 version and extension2 version, the corresponding queries will be sent:

PostgreSQL Version	Extension1 Version	Extension2 Version	Query Sent
14	1.3	2.5	Query 1
16	1.2	5	Undetermined
16	1.2	4	Query 1
16	2.5	5	Query 2

Problem

As a side note, this would make the logic significantly more complex as it needs to look into:

• Comparing versions that may or may not follow a certain standard (eg. semver).
• Undetermined cases like shown above...since if Query 1 is sent, there may be a chance that Extension2 might not support the query, and if Query 2 is sent, both PostgreSQL 14 and Extension1 may not support it.

Solution

The only solution I can see is to only compare PostgreSQL versions for >= or <=, but only == or != when it comes to extension versions and treat them as strings rather than, say, a version structure that enables comparison.

[resyfer]

@jesperpedersen Any thoughts on this solution?

[jesperpedersen]

I think we should get the information from SELECT * FROM pg_extension; during startup

[resyfer]

I think we should get the information from SELECT * FROM pg_extension; during startup

That would simplify extracting versions a lot.

However, the problems about the Undetermined case (as highlighted in the table above) as well as the semantic version still remain.

Semantic Versioning

For example...till now, in PostgreSQL, pgexporter is hinged on the major version. However, for extensions, it can be like (according to semantic versioning):

• 0.1.0
• 1.2.1-rc.2
• 3.0.0-beta

A solution can include trusting the maintainers of these extensions to version their code correctly, and only include major versions like in the case of PostgreSQL versioning.

Another solution that comes to mind is to create a struct that has atleast major and minor release versions and consider only these parameters for comparison. Changes to the column structure of an extension would typically happen in a major or a minor release.

Undetermined Cases

Where versions specified by it are on the either side of the limit (ie. one may be greater than, and the rest less that, etc.) can be classified as Undetermined as we don't know if another (with lesser requirements) can be used instead, or is it not supported.

We can leave this to the user though, and would simply result in the server not providing any metric (empty output) in undetermined cases.

[jesperpedersen]

Maybe we should do an extension-version.yaml like approach, so pgexporter scans the version upon startup and loads the file for queries...

[resyfer]

Hmmm, that would work well for just extension-only queries, however, I was thinking a bit into cases where extensions might be used alongside postgres inbuilt stuff.

[jesperpedersen]

I don't think we need to have it "built-in" aka C code - if we provide pg_stat_statements-1.10.yaml and so on might be ok.

[resyfer]

Yeah, I can agree on that. Examples can be provided for common scenarios, and people need to know what they are doing if they want to really customize it according to their need (can add as a warning in the docs about it).

The issue would be to keep up with the version releases. Should I consider only major releases or minor ones as well?

[jesperpedersen]

I would say both major and minor