Re: unlogged sequences

On Thu, Mar 31, 2022 at 12:36 PM Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
wrote:

> On 3/31/22 19:35, David G. Johnston wrote:
> > On Thu, Mar 31, 2022 at 9:28 AM Andres Freund <andres(at)anarazel(dot)de
> > <mailto:andres(at)anarazel(dot)de>> wrote:
> >
> > I agree it makes sense to have logged sequences with unlogged
> tables. We
> > should call out the behavioural change somewhere prominent in the
> > release
> > notes.
> >
>
> I'm not sure I follow. If we allow logged sequences with unlogged
> tables, there's be no behavioral change, no?
>
>
As noted below, the behavior change is in how CREATE TABLE behaves. Not
whether or not mixed persistence is allowed.

> or maybe we could
> modify pg_dump to emit UNLOGGED when the table is unlogged (but that
> would work only when using the new pg_dump).
>

Yes, the horse has already left the barn. I don't really have an opinion
on whether to leave the barn door open or closed.

>
> > If choosing option 2, are you on board with changing the behavior of
> > CREATE UNLOGGED TABLE with respect to any auto-generated sequences?
> >
>
> What behavior change, exactly? To create the sequences as UNLOGGED, but
> we'd not update the persistence after that?
>
>
Today, a newly created unlogged table with an automatically owned sequence
(serial, generated identity) has a logged sequence. This patch changes
that so the new automatically owned sequence is unlogged. This seems to be
generally agreed upon as being desirable - but given the fact that unlogged
tables will not have unlogged sequences it seems worth confirming that this
minor inconsistency is acceptable.

The first newly added behavior is just allowing sequences to be unlogged.
That is the only mandatory feature introduced by this patch and doesn't
seem contentious.

The second newly added behavior being proposed is to have the persistence
of the sequence be forcibly matched to the table. Whether this is
desirable is the main point under discussion.

David J.