@andr-sokolov

This is a very interesting feature.
If the development is available in open form, where can I view it?

@woblerr , welcome. arenadata#6 This patch is not ready to be in upstream, but it seems to be working. I want to rewrite it.

The way we have been planning to handle forks is by adding a --pg-version option (or something like that) to stanza-create that would force pgpackrest to accept the fork as version 10, 11, or whatever. In that case we would expect the fork to act exactly like Postgres does for that version.

My proposal:

• Add fork-name and fork-version version properties to the src/build/postgres/postgres.yaml file format. The default value of fork-name is PostgreSQL. Example of postgres.yaml here:

version:
  - 9.0
  - 9.1
  - 9.2
  - 9.3
  - 9.4
  - 9.4:
      fork-name: GPDB
      fork-version: 6
  - 9.5
  - 9.6
  - 10
  - 11
  - 12
  - 13
  - 14
  - 15:
      release: false

This means that GPDB 6 is based on PostgreSQL 9.4

• Add forkName (enum) and forkVersion (unsigned int) fields to PgInterface structure.
• Add FORK_NAME and FORK_VERSION macros. Their values will be checked in conditional preprocessor directives in src/postgres/interface/version.vendor.h
• Implement the search in the pgInterface array not only by version, but also by the forkName field, the value for comparison with which will be taken from the --fork-name command line parameter of stanza-create. For backward compatibility purposes, the PostgreSQL interface will be searched without this parameter.
• Use the value of fork-version property in the pgTablespaceId function. For GPDB 6 the function should return "GPDB_6_301908232". Place the pgTablespaceId function in interfaces.
• Place PG_PAGE_SIZE_DEFAULT and PG_WAL_SEGMENT_SIZE_DEFAULT values in interfaces, because PG_PAGE_SIZE_DEFAULT=32768 and PG_WAL_SEGMENT_SIZE_DEFAULT=67108864 for GPDB 6.

Are there any objections? Can I start creating a PR?

I suggest removing the fork-version property, the forkVersion field and the FORK_VERSION macro. Since the pgTablespaceId function will be in interface, the PostgreSQL version and the fork name are enough to output a string of the desired format. In addition, the path in forks may have a different format.

Closing since there is now a PR under discussion.