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: | Raw Message | Whole Thread | 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 |