Re: Always bump PG_CONTROL_VERSION? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Always bump PG_CONTROL_VERSION?
Date
Msg-id 1725979.1620945914@sss.pgh.pa.us
Whole thread Raw
In response to Re: Always bump PG_CONTROL_VERSION?  (Jan Wieck <jan@wi3ck.info>)
Responses Re: Always bump PG_CONTROL_VERSION?
List pgsql-hackers
Jan Wieck <jan@wi3ck.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: OOM in spgist insert
Next
From: Alvaro Herrera
Date:
Subject: Re: OOM in spgist insert