Re: Always bump PG_CONTROL_VERSION?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <jan(at)wi3ck(dot)info>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Always bump PG_CONTROL_VERSION?
Date: 2021-05-13 22:45:14
Message-ID: 1725979.1620945914@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <jan(at)wi3ck(dot)info> writes:
> Regardless of PG_VERSION doing the job or not, shouldn't there be a bump
> in PG_CONTROL_VERSION whenever there is a structural or semantic change
> in the control file data? And wouldn't the easiest way to ensure that be
> to bump the version with every release?

No, the way to do that is to change the version number in the commit
that changes the file's contents.

> Also, can someone give me a good reason NOT to bump the version?

It creates unnecessary churn, not to mention a false sense of
complacency. Bumping the version in the commit that changes
things is not optional, because if you don't do that then you'll
probably burn some other developer also working on HEAD. So
I don't want people thinking they can skip this because it was
done at the beginning of the development cycle. We've learned
these things the hard way for CATVERSION. I think the only reason
that PG_CONTROL version or WAL version might seem different is
that we haven't changed them often enough for people to have fresh
memories of problems.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-05-13 22:49:33 Re: OOM in spgist insert
Previous Message Alvaro Herrera 2021-05-13 22:26:56 Re: OOM in spgist insert