Re: unlogged sequences

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-06 09:12:39
Message-ID: 3f35ea46-8458-e472-0061-9d7c0ec91d26@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.04.22 19:19, Peter Eisentraut wrote:
>
> 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.

This patch is now in limbo because it appears that the logical
replication of sequences feature might end up being reverted for PG15.
This unlogged sequences feature is really a component of that overall
feature.

If we think that logical replication of sequences might stay in, then I
would like to commit this patch as well.

If we think that it will be reverted, then this patch is probably just
going to be in the way of that.

We could also move forward with this patch independently of the other
one. If we end up reverting the other one, then this one won't be very
useful but it won't really hurt anything and it would presumably become
useful eventually. What we presumably don't want is that the sequence
replication patch gets repaired for PG15 and we didn't end up committing
this patch because of uncertainty.

Thoughts?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-04-06 09:13:17 Re: API stability
Previous Message Kyotaro Horiguchi 2022-04-06 09:11:04 Re: shared-memory based stats collector - v70