Re: Always bump PG_CONTROL_VERSION?

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Always bump PG_CONTROL_VERSION?
Дата
Msg-id be4d5495-3efa-374b-f6e4-07f1366540df@pgmasters.net
обсуждение исходный текст
Ответ на Re: Always bump PG_CONTROL_VERSION?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 5/12/21 4:18 PM, Tom Lane wrote:
> David Steele <david@pgmasters.net> writes:
>> On 5/12/21 3:21 PM, Alvaro Herrera wrote:
>>> Why don't you use the PG_VERSION file in the datadir?
> 
>> Mostly because there is other data we need in pg_control and it is
>> simpler to read one file than two.
> 
> I'm disinclined to change the longstanding rule in this area for
> a reason as weak as that.

It's a bit more than that -- for instance we have pg_control in every 
backup but in order to get PG_VERSION we may need to reference a prior 
backup since it never changes. pg_control is also checked on every 
archive_command/restore_command so reading an extra file adds up when 
performance is paramount. There are also many unit tests that need to 
write this data, etc.

In short, it would be very nice to have one place to get info about a 
cluster.

> Even if we did change the rule going forward, you'd still need to
> do it properly for existing releases, so I don't see that you're
> going to save anything.

It's not really a burden for existing releases. The issue is during the 
alpha/beta phase when the CATALOG_VERSION_NO can change several times in 
a few months.

Perhaps it was unwise to frame this in the requirements for an external 
tool, but I still think eeca4cd3 and 99dd8b05a argue for it being a good 
idea.

Or perhaps we could just add the version number to pg_control? At least 
then pg_controldata could display the version.

Regards,
-- 
-David
david@pgmasters.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Always bump PG_CONTROL_VERSION?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [Patch] ALTER SYSTEM READ ONLY