Re: unlogged sequences

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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 01:16:11
Message-ID: CAKFQuwZptL3V0_jCXEUYn-GUAesVM2h+i0qq-SMZ1z6R+1mtLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 31, 2022 at 6:03 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> In this new system, does the user still get a logged sequence? If they
> get an unlogged sequence, how does dump-and-restore work? What if they
> want to still have a logged sequence? But for sequences that are
> simply owned, there is no problem here, and I think that inventing one
> would not be a good plan.
>

There is no design problem here, just coding (including special handling
for pg_upgrade). When making a sequence owned we can, without requiring
any syntax, choose to change its persistence to match the table owning it.
Or not. These are basically options 1 and 2 I laid out earlier:

https://www.postgresql.org/message-id/CAKFQuwY6GsC1CvweCkgaYi-%2BHNF2F-fqCp8JpdFK9bk18gqzFA%40mail.gmail.com

I slightly favor 1, making owned sequences implementation details having a
matched persistence mode. But we seem to be leaning toward option 2 per
subsequent emails. I'm ok with that - just give me an easy way to change
all my upgraded logged sequences to unlogged. And probably do the same if
I change my table's mode as well.

That there is less implementation complexity is nice but the end user won't
see that. I think the typical end user would appreciate having the
sequence stay in sync with the table instead of having to worry about those
kinds of details. Hence my slight favor given toward 1.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-04-01 01:16:48 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Previous Message Tom Lane 2022-04-01 01:10:00 Re: head fails to build on SLES 12 (wal_compression=zstd)