plan for major postgres version changes

[jchappelow]

Updating to support 17 is more that just letting "17" be an acceptable major version in the connection checks.

In the more general context, not just kwild use, to upgrade between major versions of postgresql such as 15->16, the standard procedure is to dump/restore or use pg_upgrade, which just helps the process. This involves down time. You must stop postgres.

More importantly, there are any changes that would change transaction execution or app hash (commit ID) computation, we need to have a mechanism in place to avoid network failure. Somehow we may use a hardfork definition to make these changes that would break consensus are coordinated, but there are still logistics of live migration from one postgres to another.

[charithabandi]

Should postgres version be part of our genesisHash, as different PG versioned nodes can end up creating different snapshots and app hashes?