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 1rzzyM-008jNM-N9 for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 14:21:14 +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 1rzzyK-007JwL-LH for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 14:21:12 +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 1rzzyK-007Jqt-4U for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 14:21:12 +0000 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzzyE-004b4C-Af for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 14:21:10 +0000 Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-6ed3cafd766so987853b3a.0 for ; Thu, 25 Apr 2024 07:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714054865; x=1714659665; 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=zUy0UCt8O2fdM3JuhYIdpRqAjVy9ZLOpIAomKZUwJY8=; b=URJ1ibAyaydnID3xWIBdp2izM9wFln4UkWs9WU4pkbZWAHr7w/X2iLqRyCuesE/SgF e0VhCjHEOiSBJpXu/2sufSeivkgBwwLKWtkbA5TGmjcd9On3dW3hZQsV6QdhtKE5UvZn hqQVjBjIXLscHF3rIEWhir7WNK8DSqUvwn4ndaBc06r8TofYLRjg8N1gpUBXhygz9xnW 8TcLsBVY00mjUaJrpxtDnVhFgTT8IfzQ60l5V4I/MAc9BDzbr3gE5TO0KhJH8RCzzm7A hTXA67lyt1Z2Qgn7lb0cjRpfnH54m1T6v32QIJHDakzYnHZCpuKtfVUvl90k7uzw8wjy mYrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714054865; x=1714659665; 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=zUy0UCt8O2fdM3JuhYIdpRqAjVy9ZLOpIAomKZUwJY8=; b=BnjwCXcQlvPWRz7O1OfgbgRbBHoRU3dLZgbL+MQWAFef3FNlt+13vS7Jybsph0IdbK m86SL5QPhIW+rjXVRx44JfO+gNzjGI3XosF3tuYLEEq6r9pr3e/smWK2+p0lmBt4hFbJ kXyyGG9gXOg/poheYlNb6MkV8fPu30wYIMS+R9NvefDX9y2Wa01Jchjp9G3xUViSO4PS +2k5YlaETJvqNTMc8bd3RFbQmAd/Tn/m9Pbqzr20929edt4eXSqiyx9Ij6mmMPBCu121 wjmZj07pCfV/ogkNGGjuJG6E6+7fKgx1XSz0t9K29z/u46EHFDQjgJn0YDe5M8Ax2b02 5dgA== X-Forwarded-Encrypted: i=1; AJvYcCXoaTyFlDK8MncPq8wLUQX7aYw2BEEc6LCEcHL1JSAerNCs84kseXv4MNu2lzxWmgWL6U5K+ro3aehebwlm3iwutfkpUgc6RwU6hGT1sWW54Gst X-Gm-Message-State: AOJu0YzTvS9lF+0K1ytG92usp/I6CcJPlm4J/5q/C5IjuootCfeUos11 7TUeIT4PcNargJNS62wb3j8dPa0E0T4b6WDixnYsYlfZVcLAI6is9JLKdFDcqR1/T9jqol+BM5i Yc/0IMV4Au+joDMTeJbm5j+cR1gk= X-Google-Smtp-Source: AGHT+IH7Zl7hvPXPO/z8qTg4qMNhJKBOfduKpcjERr0k9cacZ7uSESrycNhmTkiHl/Xvp71CU0CutIwckVGGoZnSEEs= X-Received: by 2002:a05:6a00:a16:b0:6e7:b3c4:43a4 with SMTP id p22-20020a056a000a1600b006e7b3c443a4mr6749045pfh.25.1714054864834; Thu, 25 Apr 2024 07:21:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Maxim Orlov Date: Thu, 25 Apr 2024 17:20:53 +0300 Message-ID: Subject: Re: POC: make mxidoff 64 bits To: wenhui qiu Cc: Heikki Linnakangas , Postgres hackers Content-Type: multipart/alternative; boundary="00000000000058191f0616ec7fce" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000058191f0616ec7fce Content-Type: text/plain; charset="UTF-8" On Tue, 23 Apr 2024 at 12:37, Heikki Linnakangas wrote: > 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. Yeah, I always thought so too. I believe, this is just a copy-paste. You mean, it is worth creating a separate CF entry for these fixes? On Tue, 23 Apr 2024 at 16:03, Andrey M. Borodin wrote: > BTW as a side note... I see lot's of casts to (unsigned long long), can't > we just cast to MultiXactOffset? > Actually, first versions of the 64xid patch set have such a cast to types TransactionID, MultiXact and so on. But, after some discussions, we are switched to unsigned long long cast. Unfortunately, I could not find an exact link for that discussion. On the other hand, such a casting is already used throughout the code. So, just for the sake of the consistency, I would like to stay with these casts. On Tue, 23 Apr 2024 at 16:03, wenhui qiu wrote: > 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! > I'm 100% agree. Maybe, I should return to this approach and find some benefits for having FXIDs in WAL. --00000000000058191f0616ec7fce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 23 Apr 2024 at 12:37, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
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.=
Yeah, I always thought= so too.=C2=A0 I believe, this is just a copy-paste.= =C2=A0 You mean, it is worth creating a = separate CF=C2=A0
entry for these fixes?

<= br>
On Tue, 23 Apr 2024 at 16:03= , Andrey M. Borodin <x4mmm@yande= x-team.ru> wrote:
BTW as a side note... I see lot's of casts to (unsigned long long), can= 't we just cast to MultiXactOffset?
Actually, first ver= sions of the 64xid patch set have such a cast to types TransactionID, Multi= Xact and so on.=C2=A0 But,=C2=A0
after some= discussions, we are switched to unsigned long long cast.=C2=A0 Unfortunate= ly, I could not find an exact link=C2=A0
fo= r that discussion.=C2=A0 On the other hand, such a casting is already used = throughout the code.=C2=A0 So, just for the=C2=A0
sake of the consistency, I would like to stay with these casts.


On Tue, 23 Apr = 2024 at 16:03, wenhui qiu <qiuw= enhuifx@gmail.com> wrote:
Hi Maxim Orlov
=C2=A0 =C2=A0Thank you = so much for your tireless work on this.=C2=A0Increasing the WAL size by a f= ew bytes should have very little impact with today's disk performance(L= ogical replication of this feature wal log is also increased a lot, logical= replication is a milestone new feature, and the community has been improvi= ng the logical replication of functions),I believe removing troubled postgr= esql Transaction ID Wraparound was also a milestone=C2=A0=C2=A0new feature= =C2=A0=C2=A0adding a few bytes is worth it!
I= 9;m 100% agree.=C2=A0 Maybe, I should return to this approach and find some= benefits for having FXIDs in WAL.

=C2=A0
--00000000000058191f0616ec7fce--