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 1soidZ-00DJ7C-4W for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Sep 2024 12:09:26 +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 1soidY-006MCk-Jc for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Sep 2024 12:09:24 +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 1soidY-006MAh-9I for pgsql-hackers@lists.postgresql.org; Thu, 12 Sep 2024 12:09:24 +0000 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1soidV-000ng0-Gg for pgsql-hackers@lists.postgresql.org; Thu, 12 Sep 2024 12:09:23 +0000 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a7aa086b077so112908566b.0 for ; Thu, 12 Sep 2024 05:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726142960; x=1726747760; 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=G8f80RYw+SbdaHJQyzBRioG2KHSb9+g0eG4ez8CRFeE=; b=P5VjWO52wVUqoW3Ybc5c56daENPrtJHusP07wWn4VTcoB6S3L0qJGetQUTyisc4lr6 zg6nttuA23Quv0sK2aHXEUic6W3NOLn5m3nxEctXrjoQCTv7FcnhkpKwzCUuR5EE5ida E/hsWBGs7BQciQ97RkM7cx5atF+sSc94sIItdOCzYKKP9HkoYsikHA0kqlN7kLr66gMk BJxSVF/hQzUQqovWJb/81W2+9djVGXC7q2B7cHgEWGpjjJapCiY5MbNFTltEMq0w7xwp +kOa0xmvq2TUW0gd++lRr0dsnadgi6SvH0jakH04kqL1MJ9/uiMi5GFPhYl+aKiyUWo1 GiYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726142960; x=1726747760; 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=G8f80RYw+SbdaHJQyzBRioG2KHSb9+g0eG4ez8CRFeE=; b=ZTaquN4IpjML0Y/aOawYXluacEQgqvaIvb/S9Be9N9cqRAMzblWT9AM42XL2UUtyHc TU/HCsaxfwsz0Njr5ceWEp1T9GdedeSnyDb5BRdQuCg1ZvB4CJjmehVcG3WLWJb+PDE/ yKSkH9SOwMPqxjuW7lmO4swQRcUik5h8POOr5jWsdgPZTKOwmfbIE0GqPbeOIRGjPq72 eIQN9tOdO228Q/VSkmpuyhijlilXWBuKTCjPeyB0wPSjDGEr9lrljDgK248ROA2ucdNM oJrBuO1mDtcguUfg9YSJ0LImXabH/yEimn4XJUtSgAFArgJ2JjqeME2vWEPb7VlyQ/3n rKaQ== X-Forwarded-Encrypted: i=1; AJvYcCW806dZsXjKsRSUVFo8A+D6dAb9YHS3GpHbUp5mQHPJh6JW3Skam3uxoduF1SdTzeC27h92bTlZLji6/JyI@lists.postgresql.org X-Gm-Message-State: AOJu0YxrXObjFTeUqoB4EuprOkjtdX/RNGQbvkA0Ikuov/RVoskBcJ12 zno+rRrRC8ORiWV4HqUIuJPoqAr3Cwsw+nSM+W5sT6K4H1Ntrrf4lRPSkKVDhJszSqfwFEq/uPQ fghHidE6cm4mq+RedmHdl6JGeAE8= X-Google-Smtp-Source: AGHT+IFTSY1HJ0TejS0jX92xlm5luAb4YRhGSPwM94xSO2NzOj1m6K3cpGHEEWZmSad+ci8ISwoZqQ5CCgrTa/FMYNQ= X-Received: by 2002:a17:907:3e1d:b0:a83:8591:7505 with SMTP id a640c23a62f3a-a902966f459mr272709766b.59.1726142959477; Thu, 12 Sep 2024 05:09:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Borisov Date: Thu, 12 Sep 2024 16:09:08 +0400 Message-ID: Subject: Re: POC: make mxidoff 64 bits To: Maxim Orlov Cc: Alexander Korotkov , wenhui qiu , Heikki Linnakangas , Postgres hackers Content-Type: multipart/alternative; boundary="000000000000ee6a8c0621eaf987" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ee6a8c0621eaf987 Content-Type: text/plain; charset="UTF-8" Hi, Maxim! Previously we accessed offsets in shared MultiXactState without locks as 32-bit read is always atomic. But I'm not sure it's so when offset become 64-bit. E.g. GetNewMultiXactId(): nextOffset = MultiXactState->nextOffset; is outside lock. There might be other places we do the same as well. Regards, Pavel Borisov Supabase --000000000000ee6a8c0621eaf987 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Maxim!

Previously we accessed offsets in shared MultiXactSta= te without locks as 32-bit read is always atomic. But I'm not sure it&#= 39;s so when offset become 64-bit.
E.g.=C2=A0GetNewMultiXactId():=

nextOffset =3D MultiXactState->nextOffset;
is outside lock.=C2=A0

There might be other= places we do the same as well.=C2=A0

Regards,
Pavel Borisov
Supabase


=
--000000000000ee6a8c0621eaf987--