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 1jZ2cv-0007ua-FE for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2020 01:25:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jZ2cu-0004o8-A9 for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2020 01:25:32 +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 1jZ2cu-0004kl-0j for pgsql-hackers@lists.postgresql.org; Thu, 14 May 2020 01:25:32 +0000 Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jZ2cr-0001xP-Qe for pgsql-hackers@postgresql.org; Thu, 14 May 2020 01:25:30 +0000 Received: by mail-pg1-x533.google.com with SMTP id b8so538950pgi.11 for ; Wed, 13 May 2020 18:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=XaM45s3rdjMXjEW528ZrI5QsKYGNpyg5v0gCUanVf8Y=; b=A+acjZ3TMeoOm2DLo1YG8O7FBwVkSvlxjV9H8cbh1uHjWbZIKuNSwJwCsr2npTLLMP JlNPYdU7HxOlLkUW49WN2X2A/T3VHsO4Rb4G+mQOh3vfb4lGE76TsIQSEDjcN17wRaUH 5XCOxz+hXaz0hzT8Yr56Zud/xE/3xJF/IAYBdoM6xsjOKwnBzYKA42APXwrBmsYy9rFZ t1ahiFZG3Fp2cliHgljLlp+C5Tm8IxJXDHF10vA4AjPsG9zIIYegpC/JlV4HdXFFanHU +NxabuMv2iPmToBcltYHu03p8KsUhhNVQYdXRE9QMgbyfHruNKUMU0FYckjU3DcgsQDk j4rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=XaM45s3rdjMXjEW528ZrI5QsKYGNpyg5v0gCUanVf8Y=; b=IxGHsAgVGcOIAwfdnSbm93RaSU+tbUXSsfq389Hc7mMyA/3wfq/Xi87TQYoVqOHUo8 yRLqKGGosbCPtyHrhhHBqxWGb/vfGBArDLQwDfS0piBd7Dq/MVC4n5Dmgy2o3o/m83G8 CdizkQ2P9r7h7JitsJzwoFv9S/06ee4TSz2uZB5H8jtncorNCOTqPllAvARC9nnHtuEi Vg4gM0u+lx8LHUYLYsSBmRr6Sz7NvR2fd3mQ+qDNDpHSfbz5I7JrZ/s4zmEr10FnZxM9 9yox817Nsd472fy65tvMoPEs+XToHoBilcDHDC+VQaDTN+DF8Qnbgdx+7pWOvnjIPpDe tlNw== X-Gm-Message-State: AOAM533HCGpiCowsWsv1/lI5+yJiOCYLKeQu76sKtyweF4X2/bmCXtlN JGR3NrCtL9yqGfr46zR6EaI= X-Google-Smtp-Source: ABdhPJx4uOX7Q+1AB1hr753eKRyihzoa80Jm0UkupFjYv3V20ZYfzFs9mSHOsUwd6B+/WNfmuU3hMg== X-Received: by 2002:a63:555c:: with SMTP id f28mr2013463pgm.80.1589419528674; Wed, 13 May 2020 18:25:28 -0700 (PDT) Received: from localhost (ag027197.dynamic.ppp.asahi-net.or.jp. [157.107.27.197]) by smtp.gmail.com with ESMTPSA id j5sm16977969pjf.0.2020.05.13.18.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 18:25:28 -0700 (PDT) Date: Thu, 14 May 2020 10:25:26 +0900 (JST) Message-Id: <20200514.102526.1602501255796880628.horikyota.ntt@gmail.com> To: x4mmm@yandex-team.ru Cc: pgsql-hackers@postgresql.org Subject: Re: MultiXact\SLRU buffers configuration From: Kyotaro Horiguchi In-Reply-To: References: <2BEC2B3F-9B61-4C1D-9FB5-5FAB0F05EF86@yandex-team.ru> <801D899E-9CC5-4FEE-AAA4-16D87853FD45@yandex-team.ru> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk At Wed, 13 May 2020 23:08:37 +0500, "Andrey M. Borodin" wrote in = > = > = > > 11 =CD=C1=D1 2020 =C7., =D7 16:17, Andrey M. Borodin =CE=C1=D0=C9=D3=C1=CC(=C1): > > = > > I've went ahead and created 3 patches: > > 1. Configurable SLRU buffer sizes for MultiXacOffsets and MultiXact= Members > > 2. Reduce locking level to shared on read of MultiXactId members > > 3. Configurable cache size > = > I'm looking more at MultiXact and it seems to me that we have a race = condition there. > = > When we create a new MultiXact we do: > 1. Generate new MultiXactId under MultiXactGenLock > 2. Record new mxid with members and offset to WAL > 3. Write offset to SLRU under MultiXactOffsetControlLock > 4. Write members to SLRU under MultiXactMemberControlLock But, don't we hold exclusive lock on the buffer through all the steps above? > When we read MultiXact we do: > 1. Retrieve offset by mxid from SLRU under MultiXactOffsetControlLock= > 2. If offset is 0 - it's not filled in at step 4 of previous algorith= m, we sleep and goto 1 > 3. Retrieve members from SLRU under MultiXactMemberControlLock > 4. ..... what we do if there are just zeroes because step 4 is not ex= ecuted yet? Nothing, return empty members list. So transactions never see such incomplete mxids, I believe. > What am I missing? regards. -- = Kyotaro Horiguchi NTT Open Source Software Center