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 1pClvH-0006PU-Gq for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Jan 2023 18:22:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pClvG-0000Tt-4U for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Jan 2023 18:22:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pClvF-0000Tj-PD for pgsql-hackers@lists.postgresql.org; Tue, 03 Jan 2023 18:22:01 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pClvD-0006nO-AN for pgsql-hackers@postgresql.org; Tue, 03 Jan 2023 18:22:01 +0000 Received: by mail-pl1-x630.google.com with SMTP id d3so33471723plr.10 for ; Tue, 03 Jan 2023 10:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=JiII+75Rs5rzCeoGgpOjvzOXtn0/7/99A6J5OYPLEYg=; b=IgwtTjD7udUjK3i9VAq/khGfAd4YMc65+yf1R5sO3kOPVhrCwHKjUyzbwT20leW440 MiN57wB5DeKCIKFWY/oHlAVtEkJSQ7qTL9wIaUF0FvFl3O2xhSakhjdc03xIZsz/Lspd Zh6o117sr6PKo8ZSE+7MQIosi03nAwfQAytbHRvYxmqY87rssp7G1ivZKYefxlf7WI5c Cv7Z5f2Bu5fU8BgGejLwg7tpHgWhfgS9R+xFNXX824fGm3Lyl2sNM1u/L5qnzvylYabr c21L7lRnL3kKS7RMjtqpIf2zB5tJWugkJqeUazSWEjIjbCs4df4/GEC+pEZpMSyDWPOU gQ3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JiII+75Rs5rzCeoGgpOjvzOXtn0/7/99A6J5OYPLEYg=; b=WcQiV8LA7m/DI88asjYJpVGbLPz1S2q/HFYpPW75nDf2QfZyfTA7hao77TGCJBceb9 YNC7C5ghN1uhVXT7LJOrNRKQBprxvzrNMvr7A/0OqAjCHF8vjVmOPnwPxW04DU5qOOng 9CLO2tTEoEE9y3ZdcFGGsw29nibRqmjlV8VzoweVVMTHq8fn6B3eQb/QE22UsRnoy+iJ ah9cSCvEP7y4NbIQWPbo8Bx3UipUKM+Yisc+MHlNjntBGkM9PAt0fCHtsCJkl/USDhnF OOJOioZptYVbfTC7R++JZ3w9BmQpbpMs/bLykwhngz63p4CZXrK0seVoq82O1Y1FrajC fDzw== X-Gm-Message-State: AFqh2krcxQFbsMvsoE9O0f7Sox3ePhn5nSMyIxGOZOON3brdFCwKuVmI I9KJGy2pXtqo/Q5+eN8a8/qFJyJkKnY= X-Google-Smtp-Source: AMrXdXuKYvEW2iwG0H3h7n1bes33OFpVM9vguwhhquhctsBl8w+tzIPVKMh3bbes1BIr2ErFlozmaw== X-Received: by 2002:a05:6a21:7890:b0:af:757c:ce6b with SMTP id bf16-20020a056a21789000b000af757cce6bmr67574883pzc.51.1672770117256; Tue, 03 Jan 2023 10:21:57 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id m9-20020a654c89000000b0047063eb4098sm19232907pgt.37.2023.01.03.10.21.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jan 2023 10:21:56 -0800 (PST) Date: Tue, 3 Jan 2023 10:21:55 -0800 From: Nathan Bossart To: Amit Kapila Cc: Melih Mutlu , Thomas Munro , "Hayato Kuroda (Fujitsu)" , "pgsql-hackers@postgresql.org" Subject: Re: wake up logical workers after ALTER SUBSCRIPTION Message-ID: <20230103182155.GC204418@nathanxps13> References: <20221130050441.GA1677223@nathanxps13> <20221202002130.GA2124877@nathanxps13> <20221202192101.GB2277157@nathanxps13> <20221206192551.GA3078082@nathanxps13> <20221206212954.GA3403597@nathanxps13> <20221207181145.GA3698731@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 03, 2023 at 11:43:59AM +0530, Amit Kapila wrote: > On Wed, Dec 7, 2022 at 11:42 PM Nathan Bossart wrote: >> After sleeping on this, I think we can do better. IIUC we can simply check >> for AllTablesyncsReady() at the end of process_syncing_tables_for_apply() >> and wake up the logical replication workers (which should just consiѕt of >> setting the current process's latch) if we are ready for two_phase mode. > > How just waking up will help with two_phase mode? For that, we need to > restart the apply worker as we are doing at the beginning of > process_syncing_tables_for_apply(). Right. IIRC waking up causes the apply worker to immediately call process_syncing_tables_for_apply() again, which will then proc_exit(0) as appropriate. It might be possible to move the restart logic to the end of process_syncing_tables_for_apply() to avoid this extra wakeup. WDYT? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com