Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzFqk-002kwl-Sf for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Apr 2024 13:06:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rzFqj-008YKi-IE for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Apr 2024 13:06:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzFnw-008V3c-Mn for pgsql-hackers@lists.postgresql.org; Tue, 23 Apr 2024 13:03:24 +0000 Received: from mail-yb1-xb32.google.com ([2607:f8b0:4864:20::b32]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzFnq-004FjM-8o for pgsql-hackers@lists.postgresql.org; Tue, 23 Apr 2024 13:03:23 +0000 Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-dcc71031680so5241731276.2 for ; Tue, 23 Apr 2024 06:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713877397; x=1714482197; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ETSosUrPofs9m7KEoBqEBOLUy3uRrAe7rxJx5+Szobw=; b=gVbQpTgBXX6daCc4NrPUq05XS9y6CVPRjuokmYrBKG8wAH5Ci99zLqkeNcGW66225m PbPOzmKFo6qsKXhToLbgY84TAOn6QE5qXqtdvCX6ZFu5cOtuWABBAWWjkHsWNrwOIcjZ TE0f2S2T8jJpI09RhCwqVvK22Y6vgQfLoBhkwEGs05KNF98EO9LHZal5XkZd3Utv36tX OxvAnGgaDnPdXU17D+ZIoFq9fzan2s9mC0qiYmraMJOUEejPu+H1yXgAh+njadesuBIU gZvzLBakIXx+lGnBUkHReDZVGFYDEVLDx+V/hFKbfS1oVnbkjPZiCMzR8QXfBG4dvH+u K5BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713877397; x=1714482197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ETSosUrPofs9m7KEoBqEBOLUy3uRrAe7rxJx5+Szobw=; b=eiTKWpNeWtzTYQ37yXjgh2Pv0hBbaNc9jZ/NZdzBpdMOWKBk8nqPw5Wd3OudWLICXw J7HXzr2642mvDK7KgP2WKzW6Z9isFuvjZ52chx/i1UDH5eIqVdKTSVHGuGZvPt69IuUD YA+13aS3TqqV1r7FFFW2noFyT1Lg2ezvNHSlfEv5yYma3WjRIrYwjlIiJqI2C8SWHLIE xjVbEc59KTrvagtCobgG2HPf2G+BoWZekTOt45ek+m3xszB2XQK9URo1unFczDpRUPXQ jdH8yQh4f4xDGM7zcQJeUlAVSPdKWtSP5+dqMj0AoKIYCJh0wimX2JI0sgNSddPA/qq3 qf0g== X-Forwarded-Encrypted: i=1; AJvYcCVT7/ILWKFQz/q0tBwvZGNYz9eWvwqigG3o0PjPekyT5s7ayDg/GITNxXDi59Jty6hK2gRhGPID0h9ca3c40tj3W6/aT0IVaMrwWa39fThhCQGN X-Gm-Message-State: AOJu0Yz9R9OPpiB1C3G617r1BGZ5zyJx7CNHc+zXpYWgiKjvj3A6w2qs GPf2FzQfYcsNyITP5E8FrptvYtTKPQPgDJYlQWF7bY1gGBG8f3efSxWza8VELX95iWnWFLK/BZp AlM7UigtW6hKlXyVweW7xScaYHyo= X-Google-Smtp-Source: AGHT+IG7F/yxOOqcvacsYxOTy5oqizANRemEppmjpi0aZPU6KAL+jk0LJJu0VTghvfRFgCrhjjj63Yh17ef2jM7UKds= X-Received: by 2002:a25:c790:0:b0:de5:629f:4d12 with SMTP id w138-20020a25c790000000b00de5629f4d12mr89844ybe.18.1713877397502; Tue, 23 Apr 2024 06:03:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: wenhui qiu Date: Tue, 23 Apr 2024 21:03:06 +0800 Message-ID: Subject: Re: POC: make mxidoff 64 bits To: Heikki Linnakangas Cc: Maxim Orlov , Postgres hackers Content-Type: multipart/alternative; boundary="0000000000007784dc0616c32d89" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007784dc0616c32d89 Content-Type: text/plain; charset="UTF-8" Hi Maxim Orlov Thank you so much for your tireless work on this. Increasing the WAL size by a few bytes should have very little impact with today's disk performance(Logical replication of this feature wal log is also increased a lot, logical replication is a milestone new feature, and the community has been improving the logical replication of functions),I believe removing troubled postgresql Transaction ID Wraparound was also a milestone new feature adding a few bytes is worth it! Best regards On Tue, 23 Apr 2024 at 17:37, Heikki Linnakangas wrote: > On 23/04/2024 11:23, Maxim Orlov wrote: > > PROPOSAL > > Make multixact offsets 64 bit. > > +1, this is a good next step and useful regardless of 64-bit XIDs. > > > @@ -156,7 +148,7 @@ > > ((uint32) ((0xFFFFFFFF % MULTIXACT_MEMBERS_PER_PAGE) + 1)) > > > > /* page in which a member is to be found */ > > -#define MXOffsetToMemberPage(xid) ((xid) / (TransactionId) > MULTIXACT_MEMBERS_PER_PAGE) > > +#define MXOffsetToMemberPage(xid) ((xid) / (MultiXactOffset) > MULTIXACT_MEMBERS_PER_PAGE) > > #define MXOffsetToMemberSegment(xid) (MXOffsetToMemberPage(xid) / > SLRU_PAGES_PER_SEGMENT) > > > > /* Location (byte offset within page) of flag word for a given member */ > > This is really a bug fix. It didn't matter when TransactionId and > MultiXactOffset were both typedefs of uint32, but it was always wrong. > The argument name 'xid' is also misleading. > > I think there are some more like that, MXOffsetToFlagsBitShift for example. > > -- > Heikki Linnakangas > Neon (https://neon.tech) > > > > --0000000000007784dc0616c32d89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Maxim Orlov
=C2=A0 =C2=A0Thank you so much for your = tireless work on this.=C2=A0Increasing the WAL size by a few bytes should h= ave very little impact with today's disk performance(Logical replicatio= n of this feature wal log is also increased a lot, logical replication is a= milestone new feature, and the community has been improving the logical re= plication of functions),I believe removing troubled postgresql Transaction = ID Wraparound was also a milestone=C2=A0=C2=A0new feature=C2=A0=C2=A0adding= a few bytes is worth it!

Best regards

On Tue, 23 Apr 2024 at 17:= 37, Heikki Linnakangas <hlinnaka@iki.= fi> wrote:
ht= tps://neon.tech)



--0000000000007784dc0616c32d89--