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 1pDTu2-0007TO-AJ for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 17:19:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pDTu1-0005UE-4H for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 17:19:41 +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 1pDTu0-0005SI-PI for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 17:19:40 +0000 Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pDTtx-0007Jq-Rs for pgsql-hackers@postgresql.org; Thu, 05 Jan 2023 17:19:39 +0000 Received: by mail-pg1-x52d.google.com with SMTP id 7so24957283pga.1 for ; Thu, 05 Jan 2023 09:19:37 -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=s6ym1l/c8N6i3WIO2sDwQsWQIoWkRiyeUFfc00s5ty8=; b=ifE88KSfcoMNVeztbRN0axo4sq4Ve3RRMHrZbgAdth9DNZa6/2IIZVKVzeEOJXxb3C KW4CvtTb9uKHfxIh60vZ+Xd1rKGPDHwgUP5t60QTPHYbmIZOhNoa3e42CZdMRO3+R5Wm cRwcBSnlaaYpdb8jyVU3Oemj7vDbJxGuHYyFoN1cpYXwbFUuF824a15JBXyyuJaHq6sF rqX94XwLPrD6ALvtrhgqBpzvZqgdhWnnZEp5JxU34zTsKXlDAn0CYbdkDHnQoUK5zj+4 2Ayb2MRMOk6gGdOeRESoNqQcGaxdvZ6BV6EUgYTV0xlQnlUhA1d+dz0hAWLP0QV8rHF2 FboA== 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=s6ym1l/c8N6i3WIO2sDwQsWQIoWkRiyeUFfc00s5ty8=; b=JEMZmoQe9VoY7SJuIG1lprQK4EjhS8NGWzOJwXTv6Cw/8UqcbD31Q3/hgfc8cfqvJC OvajXJO/vN1h1SbkvoahiKzgweXtFz79aLM1jUnM/EjO0grcEL4XPGPFnxhjuBzI5LX9 Fc2S6xMKZWJjnDSjOCKH4OYv6bfDKcyuJ0YMS1gQX1upI5XuHkZjRtlU+9XqYo20w3MM Dhfh94Kv45BGR7vfsgjB/DVL2Fq1YlJVxoBX1soQ4FJSDDshZhewrT0dfTePBC/dLVoF +UjPbBPoLXbS2rbvBVpbJGEjsbNcsZVGeDdMUyZpFlvdKArp08LEETXsBDe9thb2i1pe +b3Q== X-Gm-Message-State: AFqh2kobMqbd7EsXfpjXE1KIy32JBwAhXqJ6GpGaRW8V7BRiNt8XyFMd CxqNhB0FpOVpVjmAQJAeS5g= X-Google-Smtp-Source: AMrXdXv6z20vRZ3cmjFaNuKPHMmhUlricRSN034dfeZKcueHYBeiIYxut3tglqkgnmQnv0iGsx2GQA== X-Received: by 2002:a05:6a00:408c:b0:582:cec0:7751 with SMTP id bw12-20020a056a00408c00b00582cec07751mr10594914pfb.6.1672939176708; Thu, 05 Jan 2023 09:19:36 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id x28-20020aa79a5c000000b00576e4c7b9ecsm5848602pfj.214.2023.01.05.09.19.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 09:19:36 -0800 (PST) Date: Thu, 5 Jan 2023 09:19:33 -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: <20230105171933.GB299579@nathanxps13> References: <20221207181145.GA3698731@nathanxps13> <20230103182155.GC204418@nathanxps13> <20230104173304.GA296349@nathanxps13> <20230105041237.GA189619@nathanxps13> <20230105044622.GA256534@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 Thu, Jan 05, 2023 at 11:34:37AM +0530, Amit Kapila wrote: > On Thu, Jan 5, 2023 at 10:16 AM Nathan Bossart wrote: >> In v12, I moved the restart for two_phase mode to the end of >> process_syncing_tables_for_apply() so that we don't need to rely on another >> iteration of the loop. > > This should work but it is better to add a comment before calling > CommandCounterIncrement() to indicate that this is for making changes > to the relation state visible. Will do. > Thinking along similar lines, won't apply worker need to be notified > of SUBREL_STATE_SYNCWAIT state change by the tablesync worker? wait_for_worker_state_change() should notify the apply worker in this case. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com