On Tue, February 12, 2013 17:19, Alvaro Herrera wrote:
> Erik Rijkers wrote:
>> On Tue, February 12, 2013 17:01, Alvaro Herrera wrote:
>> > Erik Rijkers wrote:
>> >> On Tue, February 12, 2013 15:55, Alvaro Herrera wrote:
>> >> > Create libpgcommon, and move pg_malloc et al to it
>> >> >
>> >>
>> >> If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as
>> >> such.
>> >
>> > Hmm? I don't think this patch requires an initdb at all. It doesn't
>> > touch the database contents at all, does it?
>> >
>> > Patches that force an initdb are flagged as such by bumping
>> > CATALOG_VERSION_NO.
>> >
>>
>> I got this:
>>
>> The database cluster was initialized with PG_CONTROL_VERSION 934, but the server was compiled
>> with
>> PG_CONTROL_VERSION 935
>> HINT: It looks like you need to initdb
>>
>>
>> But I immediately admit that I could well be mistaken; it may have been an older commit that
>> triggered this complaint of 'needing initdb' on this particular machine. My apologies.
>
> Ah, yes, that's 62401db45c.
>
> I'm not sure are you suggesting, though. Are you saying that the commit
> message should explicitely state "this patch requires initdb" or some
> such?
>
I was under the impression that this was habitually done in commit messages, but looking back
through the commitlog messages it's not all that clear although sometimes catversion bumps are
explicitly mentioned.
Let's just say that an explicit mention/warning is useful for me, so probably for some others too.
At the same time I'll start monitoring PG_CONTROL_VERSION and CATALOG_VERSION a bit more closely.
That's easy enough too of course...
Thanks,
Erik Rijkers