Re: unlogged sequences - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: unlogged sequences
Date
Msg-id ed6f0141-5d36-88f1-b7fe-d509dc763fc3@enterprisedb.com
Whole thread Raw
In response to Re: unlogged sequences  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: unlogged sequences
Re: unlogged sequences
List 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
Attachment

pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Correct docs re: rewriting indexes when table rewrite is skipped
Next
From: Devrim Gündüz
Date:
Subject: head fails to build on SLES 12