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 1uU6a2-00FfSl-Oh for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jun 2025 16:33:06 +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 1uU6a0-00DZvI-OY for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jun 2025 16:33:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uU6a0-00DZv9-FR for pgsql-hackers@lists.postgresql.org; Tue, 24 Jun 2025 16:33:05 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uU6Zy-003rAC-1R for pgsql-hackers@lists.postgresql.org; Tue, 24 Jun 2025 16:33:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 55OGX09b957698; Tue, 24 Jun 2025 12:33:00 -0400 From: Tom Lane To: Ashutosh Bapat cc: pgsql-hackers@lists.postgresql.org Subject: Re: Logrep launcher race conditions leading to slow tests In-reply-to: References: <817604.1750723007@sss.pgh.pa.us> Comments: In-reply-to Ashutosh Bapat message dated "Tue, 24 Jun 2025 17:20:10 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <957696.1750782780.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Tue, 24 Jun 2025 12:33:00 -0400 Message-ID: <957697.1750782780@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ashutosh Bapat writes: > On Tue, Jun 24, 2025 at 5:26 AM Tom Lane wrote: >> 4. In process_syncing_tables_for_apply (the other caller of >> logicalrep_worker_launch), it seems okay to ignore the >> result of logicalrep_worker_launch, but I think it should >> fill hentry->last_start_time before not after the call. >> Otherwise we might be changing a hashtable entry that's >> no longer relevant to this worker. > A hash entry is associated with a table, not the worker. In case the > worker fails to launch it records the time when worker launch for that > table was attempted so that next attempt could be well-spaced in time. > I am not able your last statement, what is the entry's relevance to > the worker. > But your change makes this code similar to ApplyLauncherMain(), which > deals with subscriptions. +1 for the consistency. Yeah, mainly I want to make it look more like ApplyLauncherMain(). It's true right now that nothing outside this process will touch that hash table, so it doesn't matter which way we do it. But if we were to switch that table to being shared state, this'd be an unsafe order of operations for the same reasons it'd be wrong to do it like that in ApplyLauncherMain(). regards, tom lane