Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n27qm-0005uQ-N2 for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Dec 2021 08:28:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n27ql-0008SM-J4 for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Dec 2021 08:28:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n27ql-0008SD-7I for pgsql-hackers@lists.postgresql.org; Tue, 28 Dec 2021 08:28:51 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n27qe-0004LA-OJ for pgsql-hackers@lists.postgresql.org; Tue, 28 Dec 2021 08:28:50 +0000 Received: by mail-ed1-x52a.google.com with SMTP id b13so70926207edd.8 for ; Tue, 28 Dec 2021 00:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9tejop6INt0Q92cXZt3ZUumoTMdOOdd0GRh9Irf6jxs=; b=U3gal4eBNJUIFj1pL6reWh0cBECA7EwKdXamqjIqPw/plMoapGIkAfnC1MP6qhBC3/ 1dao9zFv/9xKhwU0RYchznd+gbpNmf/iHZkMEy1ihchcNPdAzDk/y37POKjsZubgAitl ulVWgn8z8oFo1CITPVgO7neGOu42lWU/UlcWMnNS9m1vV8FLw+bGHf3edCf2mAHWbxqZ TbC+xcukJHvhPj07eHAas0gtKK8Gn/DGI4x3cX9AMau+sAn4Br8Rf/E2UVrKc49bGopf SIUmiOOVnhUa4ZXT/QUF88cv6bb3S0BAHABUopSai4r8tsL1If30ShPEFWPucSstRFOq NGUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9tejop6INt0Q92cXZt3ZUumoTMdOOdd0GRh9Irf6jxs=; b=ZgMJ2he527oNul6MSpdRnzBcM3WGE46UjCYENCjaQDYHx6O48dKimDkVu5e295sKWA 6xM4HIPcufEFZ3pCe1P+InaAUWscLrUKbEc9rxjh4aoAbmk29L99ZKGDQOtwzqVlotqJ uUoSTxvTU+7a25/8rOaxBN6KI6rAcVDrdpw07sanH2AS7tUt3M+woSD2qy4nmBaoYHLy SUGQeTY4zr9hvcLUF0WXKoxlOdZY9lsHxnBb4P2kK3j/kVlZo3ggIwVlwRiGqBhWgPo/ MadZzQ0yUs7Ce1wZAV8atbRSDpFzRlxctZ7052ydI86aJqbMh74fVmdtCOFrS+uLg/yV 26sg== X-Gm-Message-State: AOAM532RE/oBB5SXgw0CdH4Mi9DyHGDtsMp4PxWnaUBL+dQxmuoUmCM+ 11po0KEjoX6FyMNeRsQ/VFOH8284fO3O7ars/mg= X-Google-Smtp-Source: ABdhPJzIdfgYxXaYKfYOuSB0J9DsYVMxFztWS+oNJN65fVAplxtdxbo0143XKsHofumRqPz9isXyCtJu+9jpNN/cNPE= X-Received: by 2002:aa7:c550:: with SMTP id s16mr19030082edr.320.1640680122359; Tue, 28 Dec 2021 00:28:42 -0800 (PST) MIME-Version: 1.0 References: <20211224.143725.1750248643492340056.horikyota.ntt@gmail.com> <20211224.170451.116141220257426861.horikyota.ntt@gmail.com> <27f005a6-63f7-2ca9-2ab3-92fe9110e224@enterprisedb.com> In-Reply-To: From: Sascha Kuhl Date: Tue, 28 Dec 2021 09:28:30 +0100 Message-ID: Subject: Re: sequences vs. synchronous replication To: Fujii Masao Cc: Tomas Vondra , Kyotaro Horiguchi , Tom Lane , Peter Eisentraut , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000e2228305d4309bf3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e2228305d4309bf3 Content-Type: text/plain; charset="UTF-8" Sequence validation by step, in total is great. If the sequence is Familie or professional, does it make sense to a have a total validation by an expert. I can only say true by chi square Networks, but would a medical opinion be an improvement? Fujii Masao schrieb am Di., 28. Dez. 2021, 07:56: > > > On 2021/12/24 19:40, Tomas Vondra wrote: > > Maybe, but what would such workload look like? Based on the tests I did, > such workload probably can't generate any WAL. The amount of WAL added by > the change is tiny, the regression is caused by having to flush WAL. > > > > The only plausible workload I can think of is just calling nextval, and > the cache pretty much fixes that. > > Some users don't want to increase cache setting, do they? Because > > - They may expect that setval() affects all subsequent nextval(). But if > cache is set to greater than one, the value set by setval() doesn't affect > other backends until they consumed all the cached sequence values. > - They may expect that the value returned from nextval() is basically > increased monotonically. If cache is set to greater than one, subsequent > nextval() can easily return smaller value than one returned by previous > nextval(). > - They may want to avoid "hole" of a sequence as much as possible, e.g., > as far as the server is running normally. If cache is set to greater than > one, such "hole" can happen even thought the server doesn't crash yet. > > > > FWIW I plan to explore the idea of looking at sequence page LSN, and > flushing up to that position. > > Sounds great, thanks! > > Regards, > > -- > Fujii Masao > Advanced Computing Technology Center > Research and Development Headquarters > NTT DATA CORPORATION > > > --000000000000e2228305d4309bf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sequence validation by step, in total is great. If the se= quence is Familie or professional, does it make sense to a have a total val= idation by an expert. I can only say true by chi square Networks, but would= a medical opinion be an improvement?

<= div dir=3D"ltr" class=3D"gmail_attr">Fujii Masao <masao.fujii@oss.nttdata.com> schrieb am Di.= , 28. Dez. 2021, 07:56:


On 2021/12/24 19:40, Tomas Vondra wrote:
> Maybe, but what would such workload look like? Based on the tests I di= d, such workload probably can't generate any WAL. The amount of WAL add= ed by the change is tiny, the regression is caused by having to flush WAL.<= br> >
> The only plausible workload I can think of is just calling nextval, an= d the cache pretty much fixes that.

Some users don't want to increase cache setting, do they? Because

- They may expect that setval() affects all subsequent nextval(). But if ca= che is set to greater than one, the value set by setval() doesn't affec= t other backends until they consumed all the cached sequence values.
- They may expect that the value returned from nextval() is basically incre= ased monotonically. If cache is set to greater than one, subsequent nextval= () can easily return smaller value than one returned by previous nextval().=
- They may want to avoid "hole" of a sequence as much as possible= , e.g., as far as the server is running normally. If cache is set to greate= r than one, such "hole" can happen even thought the server doesn&= #39;t crash yet.


> FWIW I plan to explore the idea of looking at sequence page LSN, and f= lushing up to that position.

Sounds great, thanks!

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION


--000000000000e2228305d4309bf3--