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 1pD7dZ-0007xx-FT for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jan 2023 17:33:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pD7dY-0000dx-0S for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jan 2023 17:33:12 +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 1pD7dX-0000do-Lq for pgsql-hackers@lists.postgresql.org; Wed, 04 Jan 2023 17:33:11 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pD7dU-0004l7-Vs for pgsql-hackers@postgresql.org; Wed, 04 Jan 2023 17:33:11 +0000 Received: by mail-pl1-x633.google.com with SMTP id jl4so30282077plb.8 for ; Wed, 04 Jan 2023 09:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vZ6xC9fwsd15ywkIA0AHPBID02zTeXCvXiFhagN2YHI=; b=Jq1630ZWgCib+HC5HPVBVwFv6jTP1CbB+6msn3+jlc5mRVGY1Sy7t2UKIdN3bOMyeL a3SVvR9ig53Xb4Y7qojUHLADfvIIoRv7h6dfZvUyTJks+zOp55fDUBxGaRzTIJRbZyr3 8MlBkusW7NT5uYJtRpmZVhRa1599/g01r/rNEm+NA7rsgYQcz0u8TTJRBWSEp2NzrpB7 HY571ok2Ict5ci2m1AzxVPPYLvQVMXTOIWvo/4H2YU6bPOQb63P5iWUQSL56bXNYweqv KxdNaQgKZoqqwvSZzQTg8WdP5DAISYmcTbSUdZo3QU2hI8xA/DGzIEm9Yduhi+DIEf0N +a+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=vZ6xC9fwsd15ywkIA0AHPBID02zTeXCvXiFhagN2YHI=; b=BJfmjbWE56bxNfsW255RMXu84TCGD03PMGH28Z56OjBfYOdNef/ZlAuA9cPND3MNXM Z/4OeBVJOaDkIkNdwPl3MyCAdgp78tkTf0QwUS1yi4QsxjEBqIauYDsRx8kbygDOqNIk WHmqZkc+g8TA8fqAzmT66okF5LQOmbqnaBei4/agML/bxNum3eWch8IX3haecR6F0MZh 0AGTPU0zWzULlqvdLvEKnRE7gv8HXO5qsdRGnZyAEjNgTS6aFasalwo/BcSBQTYba7gp D3XWsXnTyOKVePW+a/TkQVfAvWHOjlUjXYKKpdqaKtqmLc2CYrCAsecwH++nkee+bm4B BuMA== X-Gm-Message-State: AFqh2kotQUqi9sqm07bcYCWeV0YmR0n1MGxnVlHZI872qSX4khj/yfpW hRfn2SdQR018ChLsBMD7Nkg= X-Google-Smtp-Source: AMrXdXv637+yQuvH9NKnwQBMyWjwW9iu6Q+si5IYcujueCfRD21YBYhCeEu9meQtlPtvGfJmh9zEYQ== X-Received: by 2002:a17:902:7c95:b0:192:a04b:76be with SMTP id y21-20020a1709027c9500b00192a04b76bemr26117937pll.25.1672853587006; Wed, 04 Jan 2023 09:33:07 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id l6-20020a170903244600b001869f2120absm24374308pls.294.2023.01.04.09.33.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Jan 2023 09:33:06 -0800 (PST) Date: Wed, 4 Jan 2023 09:33:04 -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: <20230104173304.GA296349@nathanxps13> References: <20221202002130.GA2124877@nathanxps13> <20221202192101.GB2277157@nathanxps13> <20221206192551.GA3078082@nathanxps13> <20221206212954.GA3403597@nathanxps13> <20221207181145.GA3698731@nathanxps13> <20230103182155.GC204418@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 04, 2023 at 09:41:47AM +0530, Amit Kapila wrote: > I am not sure if I understand the problem you are trying to solve with > this part of the patch. Are you worried that after we mark some of the > relation's state as READY, all the table syncs are in the READY state > but we will not immediately try to check the two_pahse stuff and > probably the apply worker may sleep before the next time it invokes > process_syncing_tables_for_apply()? Yes. > If so, we probably also need to > ensure that table_states_valid is marked false probably via > invalidations so that we can get the latest state and then perform > this check. I guess if we can do that then we can directly move the > restart logic to the end. IMO this shows the advantage of just waking up the worker. It doesn't change the apply worker's behavior besides making it more responsive. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com