| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: unlogged sequences |
| Date: | 2022-04-03 17:19:38 |
| Message-ID: | 30556154-ab75-902d-e30c-dad4a1999125@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01.04.22 18:31, Peter Eisentraut wrote:
>> Consider that an identity sequence creates an "internal" dependency
>> and a serial sequence creates an "auto" dependency.
>>
>> An "internal" dependency means that the internal object shouldn't
>> really be operated on directly. (In some cases it's allowed for
>> convenience.) So I think in that case the sequence must follow the
>> table's persistence in all cases. This is accomplished by setting the
>> initial persistence to the table's, making ALTER TABLE propagate
>> persistence changes, and prohibiting direct ALTER SEQUENCE SET.
>
> But to make pg_upgrade work for identity sequences of unlogged tables,
> we need to allow ALTER SEQUENCE ... SET LOGGED on such sequences. Which
> I guess is not a real problem in the end.
Here is an updated patch that fixes this pg_dump/pg_upgrade issue and
also adds a few more comments and documentation sentences about what
happens and what is allowed. I didn't change any behaviors; it seems we
didn't have consensus to do that.
These details about how tables and sequences are linked or not are
pretty easy to adjust, if people still have some qualms.
| Attachment | Content-Type | Size |
|---|---|---|
| v6-0001-Unlogged-sequences.patch | text/plain | 26.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-04-03 18:50:26 | Re: unlogged sequences |
| Previous Message | Joseph Koshakow | 2022-04-03 17:00:48 | Re: Fix overflow in DecodeInterval |