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.96) (envelope-from ) id 1wkCJ0-000WlV-2t for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Jul 2026 02:58:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wkCIz-00AsWo-2T for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Jul 2026 02:58:33 +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.96) (envelope-from ) id 1wkCIz-00AsWf-1Y for pgsql-hackers@lists.postgresql.org; Thu, 16 Jul 2026 02:58:33 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wkCIx-00000000Rdb-0Uxm for pgsql-hackers@postgresql.org; Thu, 16 Jul 2026 02:58:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 66G2wSKT3621809; Wed, 15 Jul 2026 22:58:28 -0400 From: Tom Lane To: vignesh C cc: Noah Misch , Amit Kapila , pgsql-hackers@postgresql.org Subject: Re: sequencesync worker race with REFRESH SEQUENCES In-reply-to: References: <20260710045217.f0.noahmisch@microsoft.com> <20260715025809.cd.noahmisch@microsoft.com> <20260715115601.fd.noahmisch@microsoft.com> <3614163.1784163070@sss.pgh.pa.us> Comments: In-reply-to vignesh C message dated "Thu, 16 Jul 2026 08:11:51 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3621807.1784170708.1@sss.pgh.pa.us> Date: Wed, 15 Jul 2026 22:58:28 -0400 Message-ID: <3621808.1784170708@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk vignesh C writes: > On Thu, 16 Jul 2026 at 06:21, Tom Lane wrote: >> That is, after checking for the "insufficient privileges" case, >> we aren't waiting long enough for the new seqsync worker to quiesce. >> This wasn't a problem before f38afa4ab, because it wasn't an error >> condition for that worker to still be running. > I think we can simply remove the REFRESH SEQUENCES command and add a > comment explaining that the sequence synchronization worker is > restarted automatically while there are sequences that are not yet in > the READY state. Well, that would fix this test, but I wonder if this result isn't telling us that f38afa4ab has created a failure condition that will bite real users. Why would the user issuing REFRESH SEQUENCES be aware of whether there's a sync worker running right then? Why should it be his problem to avoid that? regards, tom lane