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 1qZTqs-005XJj-EP for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Aug 2023 10:15:38 +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 1qZTqr-001Rko-1O for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Aug 2023 10:15:36 +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 1qZTqq-001Rkg-NH for pgsql-hackers@lists.postgresql.org; Fri, 25 Aug 2023 10:15:36 +0000 Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qZTqj-000s97-Ju for pgsql-hackers@postgresql.org; Fri, 25 Aug 2023 10:15:35 +0000 Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3a88e1a5286so537414b6e.3 for ; Fri, 25 Aug 2023 03:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692958529; x=1693563329; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0nThXF+0WjrSrJQeCh7xiVhxk3yOflTNDdJ6oYL9Zdc=; b=BhQMgjL9Ad5LsOR1ukCnrkjNqczCdt/gDH0kIOdrOxrC9Tr9cKypCbTPsMNXgJMs8t kEvy3Oak2MPz0WPtr9BXW+wlW4ASW89Q0tXQfmkX621nmrq9IEkxIcpqmgkby86oG5zW NG0n1YcL/Jo3oCIr0vk/46lka6L23659gI9TK6NG/tQbITvHcQPyX1qfl8NxJo8od0rj T/GiWQR9Uh9G0BCRvx4QFukra1b3Xu8+go311sLZMpQbpG2gDQaFUmEDfjdDMCdXFN87 D8oyd1vJpxHJlGtXbUBL6/xUyYhz9nPbBET2SMK6I0RucQWx4tIGs0XxiCMHHFQLVf+L vgig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692958529; x=1693563329; h=content-transfer-encoding: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=0nThXF+0WjrSrJQeCh7xiVhxk3yOflTNDdJ6oYL9Zdc=; b=E3KTuoExwnFr8JUtwz5dJJoKzc/AshbHZkmgINTstuxStIrUzd/tUC2EUGN2G7aMxx Bd9bXSd4+n0o2wgrTN1kbYTEOCxT1QcQokvB7dhqyAtkISFL82luHCA1pPnMhg+D0ybG H4aEdOzoeQhQrC74ohg+p30VRTyDw5+yNgk3rwQmiuSn0em83lxjwna5PmgwQQeWXCoz KNHCIvEfmeQ5NUYtJIHSK2T3VE3q2cjEp9sD2Z+XwE0mJTAwWCXBESXWZAPHMpznma4C hF5mAtn/7Wbn2p4MTZrY7HhqdE6ZwatW9nTcTDJEMll9+lBu6B8+miPX1isl059rhz6+ DssQ== X-Gm-Message-State: AOJu0YxfRjVVr982/PXwsuhOXlfOaBH6TTwMxgLd/nHHk7IoV1wiVIgW 1V5RZ3s8/HC1N/IR+XWpYreweVuxKZiQKJweUcw= X-Google-Smtp-Source: AGHT+IGOHXfjREpq2ULJaJgttFYEiAA5A5Xwvmf0ITzlAHICyYho8GIT8lYUUKfnbKlK/od7E1zgUrGxp5uyifr26yo= X-Received: by 2002:a05:6808:2185:b0:3a7:48eb:2de2 with SMTP id be5-20020a056808218500b003a748eb2de2mr3542469oib.26.1692958528831; Fri, 25 Aug 2023 03:15:28 -0700 (PDT) MIME-Version: 1.0 References: <20230824075044.cn4slf6wgvkpdc7f@alvherre.pgsql> In-Reply-To: From: Amit Kapila Date: Fri, 25 Aug 2023 15:45:17 +0530 Message-ID: Subject: Re: subscription/015_stream sometimes breaks To: Alvaro Herrera Cc: "Zhijie Hou (Fujitsu)" , Thomas Munro , pgsql-hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Aug 24, 2023 at 3:48=E2=80=AFPM Amit Kapila wrote: > > On Thu, Aug 24, 2023 at 1:20=E2=80=AFPM Alvaro Herrera wrote: > > > > On 2023-Aug-24, Amit Kapila wrote: > > > > > On Wed, Aug 23, 2023 at 1:31=E2=80=AFPM Alvaro Herrera wrote: > > > > > > Hmm, I think if worker->in_use is false, we shouldn't consult the r= est > > > > of the struct at all, so I propose to add the attached 0001 as a mi= nimal > > > > fix. > > > > > > I think that way we may need to add the check for in_use before > > > accessing each of the LogicalRepWorker struct fields or form some rul= e > > > about which fields (or places) are okay to access without checking > > > in_use field. > > > > As far as I realize, we have that rule already. It's only a few > > relatively new places that have broken it. I understand that the in_us= e > > concept comes from the one of the same name in ReplicationSlot, except > > that it is not at all documented in worker_internal.h. > > > > So I propose we do both: apply Zhijie's patch and my 0001 now; and > > somebody gets to document the locking design for LogicalRepWorker. > > > > Agreed. > Pushed both the patches. --=20 With Regards, Amit Kapila.