Re: unlogged sequences

On 3/31/22 21:55, David G. Johnston wrote:
> On Thu, Mar 31, 2022 at 12:36 PM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com <mailto: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>
> > <mailto: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.
>

Right. The latest version of the patch also prohibits changing
persistence of owned sequences directly. But that's probably considered
to be part of the second behavior.

I agree the first part is not contentious, so shall we extract this part
of the patch and get that committed for PG15? Or is that too late to
make such changes to the patch?

regards

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