Re: Online PostgreSQL version() updates

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Online PostgreSQL version() updates
Date: 2026-04-01 12:47:19
Message-ID: 97d218e241183a7a9dd634cc30f2ec17d1191878.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2026-04-01 at 17:01 +0500, Andrey Borodin wrote:
>
> > On 1 Apr 2026, at 15:48, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> wrote:
> >
> > Attached is a patch that allows superusers to update the version() of
> > their running system with a simple SQL call: SELECT
> > pg_update_version(version_num, 'version_short', 'the full version()
> > outout')
>
> While I find this proposal very useful, I think the interface can be improved.
>
> Consider SELECT pg_update_version(commit_hash) so we can do stuff like
> SELECT pg_update_version('REL_18_2') or SELECT pg_update_version('HEAD~10000').
> In future we can even create a bisect facility, so when user encounters a bug
> in their production they can iterate over several commits to trace root cause.

I don't think that has to go into the first release; perhaps such functionality
can be added later.

But the patch, as it is, is missing something important: the "internal" parameters
"server_version" and "server_version_num" need to reflect the changed version.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavlo Golub 2026-04-01 12:49:05 Re[2]: [PATCH] pg_stat_statements: add last_execution_start column
Previous Message Amit Kapila 2026-04-01 12:35:01 Re: Adding REPACK [concurrently]