Re: unlogged sequences

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: unlogged sequences
Date: 2022-04-01 00:42:29
Message-ID: 96015387-a21e-5f29-fe85-f5eefe6201b5@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/1/22 02:25, Robert Haas wrote:
> On Thu, Mar 31, 2022 at 10:14 AM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>> * 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.
>
> Wait, what? I don't understand why we would want to do either of these things.
>
> It seems to me that it's totally fine to use a logged table with an
> unlogged sequence, or an unlogged table with a logged sequence, or any
> of the other combinations. You get what you ask for, so make sure to
> ask for what you want. And that's it.
>
> If you say something like CREATE [UNLOGGED] TABLE foo (a serial) it's
> fine for serial to attribute the same persistence level to the
> sequence as it does to the table. But when that's dumped, it's going
> to be dumped as a CREATE TABLE command and a CREATE SEQUENCE command,
> each of which has a separate persistence level. So you can recreate
> whatever state you have.
>

Well, yeah. I did this because the patch was somewhat inconsistent when
handling owned sequences - it updated persistence for owned sequences
when persistence for the table changed, expecting to keep them in sync,
but then it also allowed operations that'd break it.

But that started a discussion about exactly this, and AFAICS there's
agreement we want to allow the table and owned sequences to have
different persistence values.

The discussion about the details is still ongoing, but I think it's
clear we'll ditch the restrictions you point out.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-04-01 00:44:08 Re: unlogged sequences
Previous Message Robert Haas 2022-04-01 00:39:28 Re: head fails to build on SLES 12 (wal_compression=zstd)