Re: Add 64-bit XIDs into PostgreSQL 15

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: Add 64-bit XIDs into PostgreSQL 15
Дата
Msg-id CAJ7c6TMYYP69h10fB_zGa8_2dBZ4BXqA3s+32tnEiEQjaJgc6g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add 64-bit XIDs into PostgreSQL 15  (Pavel Borisov <pashkin.elfe@gmail.com>)
Ответы Re: Add 64-bit XIDs into PostgreSQL 15  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
Hi hackers,

[ Excluding my personal e-mail from cc:, not sure how it got there.
Please don't cc: to afiskon@gmail.com, I'm not using it for reading
pgsql-hackers@. ]

> I agree with Alexander, that notifications for DBA are a little bit
> outside the scope of the activity in this thread unless we've just
> dropped some existing notifications, considering they're not
> significant anymore. If that was the point, please Chris mention what
> existing notifications you want to return. I don't think it's a big
> deal to have the patch with certain notifications inherited from
> Master branch.

To clarify a bit: currently we DO notify the user about the upcoming
wraparound point [1]:

"""
If for some reason autovacuum fails to clear old XIDs from a table,
the system will begin to emit warning messages like this when the
database's oldest XIDs reach forty million transactions from the
wraparound point:

WARNING:  database "mydb" must be vacuumed within 39985967 transactions
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in
that database.
"""

So I'm not sure how the notification Chris proposes should differ or
why it is in scope of this patch. If the point was to make sure
certain existing notifications will be preserved - sure, why not.

[1]: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

-- 
Best regards,
Aleksander Alekseev



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

Предыдущее
От: Pavel Borisov
Дата:
Сообщение: Re: Add 64-bit XIDs into PostgreSQL 15
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Damage control for planner's get_actual_variable_endpoint() runaway