Re: unlogged sequences

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: unlogged sequences
Дата
Msg-id ed6f0141-5d36-88f1-b7fe-d509dc763fc3@enterprisedb.com
обсуждение исходный текст
Ответ на Re: unlogged sequences  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: unlogged sequences  (Andres Freund <andres@anarazel.de>)
Re: unlogged sequences  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi,

Here's a slightly improved patch, adding a couple checks and tests for
owned sequences to ensure both objects have the same persistence. In
particular:

* When linking a sequence to a table (ALTER SEQUENCE ... OWNED BY),
there's an ereport(ERROR) if the relpersistence values do not match.

* Disallow changing persistence for owned sequences directly.


But I wonder about two things:

1) Do we need to do something about pg_upgrade? I mean, we did not have
unlogged sequences until now, so existing databases may have unlogged
tables with logged sequences. If people run pg_upgrade, what should be
the end result? Should it convert the sequences to unlogged ones, should
it fail and force the user to fix this manually, or what?

2) Does it actually make sense to force owned sequences to have the same
relpersistence as the table? I can imagine use cases where it's OK to
discard and recalculate the data, but I'd still want to ensure unique
IDs. Like some data loads, for example.



regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения

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

Предыдущее
От: James Coleman
Дата:
Сообщение: Re: Correct docs re: rewriting indexes when table rewrite is skipped
Следующее
От: Devrim Gündüz
Дата:
Сообщение: head fails to build on SLES 12