Re: unlogged sequences - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: unlogged sequences
Date
Msg-id c2b7ad79-e040-ebb0-b342-66eede971ef4@enterprisedb.com
Whole thread Raw
In response to Re: unlogged sequences  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: unlogged sequences  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: unlogged sequences  (Robert Haas <robertmhaas@gmail.com>)
Re: unlogged sequences  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On 01.04.22 18:22, Peter Eisentraut wrote:
> 
> On 01.04.22 00:43, Tomas Vondra wrote:
>> Hmm, so what about doing a little bit different thing:
>>
>> 1) owned sequences inherit persistence of the table by default
>>
>> 2) allow ALTER SEQUENCE to change persistence for all sequences (no
>> restriction for owned sequences)
>>
>> 3) ALTER TABLE ... SET [UN]LOGGED changes persistence for sequences
>> matching the initial table persistence
> 
> 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.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: unlogged sequences
Next
From: "David G. Johnston"
Date:
Subject: Re: unlogged sequences