On Thu, Mar 31, 2022 at 12:36 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote:
> On 3/31/22 19:35, David G. Johnston wrote: > > On Thu, Mar 31, 2022 at 9:28 AM Andres Freund <and...@anarazel.de > > <mailto:and...@anarazel.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.
