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 1qkUNU-00EejG-Q0 for pgsql-hackers@arkaria.postgresql.org; Sun, 24 Sep 2023 19:02:48 +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 1qkUNT-00AGi9-9R for pgsql-hackers@arkaria.postgresql.org; Sun, 24 Sep 2023 19:02:47 +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 1qkUNS-00AGhx-UZ for pgsql-hackers@lists.postgresql.org; Sun, 24 Sep 2023 19:02:46 +0000 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qkUNN-007LNL-Qr for pgsql-hackers@lists.postgresql.org; Sun, 24 Sep 2023 19:02:46 +0000 Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-d868d8363e6so1662676276.2 for ; Sun, 24 Sep 2023 12:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695582160; x=1696186960; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sEASSDaHJizY/H7BUJ0/ZkwRZySaFttW+zwTONoLlAQ=; b=RIYe+NiSsY4B9x8FN1Bvsu3DKxyorQRuZulGhTCUfjiOOAB2iaSgWmRIfGCz7/kWGN 7w4mmxiAs8TmSOOyRLOTr+m8qOt/6D1VfSb2xNXpBbIUxXWAN7YIIEWdX/5gmV6JQwfd bM5984rV11IFmVNBAAD50Zh4gtd0CmmXmD7+597kACs8f4xGOR80L9xyV+oA+k8aayIa wh7KO7sPJ5eMFMOZ/X6OVSkpiKBlS5BBSJ/phcNOcHAmqmn+wongG27742X89FoVutrb ubwSyRp8LC9By8Xyvic+dTa9ESb5DhM9gV9c3QdDlZC0NpYNWLz9F/DfjDkTHMljIAtj r6ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695582160; x=1696186960; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sEASSDaHJizY/H7BUJ0/ZkwRZySaFttW+zwTONoLlAQ=; b=q2I16xv4eHu6l6QCh8p77uitr6J2mt8uTK/j4wuRQkO/PWjnpnm37zkWhfDVixl7ht WITcRyFm3iUyj+ZGamDNwFvq6L0RE/4Y4OZp3Xy61ARy7MBqaehncqKa/PnrChL252kw TAP3DB3TPBlSYem8AXIfv6WAw0EMHuqbG8Y5sml1YZRMEQ+Nsp6D1fHkkZKfaF8jZrg7 qCAUtMjSS5sSyL37Rt9UXYGMr3p22V2Dxgc93M4OaouwFF1GHRSsEISsdLssIO4sThIV N29J41pDfgFjq8TQRe6tLYsrayxkRVttrSgoU8iEiYjcqX1ELS0nBTB7H24pldEMwhnI 2vsw== X-Gm-Message-State: AOJu0Yz7ntoCOwl0hwJH1b55hjBDJmq50qRv6WDKgX5SmO6h4qhKJoB9 UUmNLKWBbFk29L4NzlD/yR816rHT3cGGY/tXrSM= X-Google-Smtp-Source: AGHT+IERnFYuFJjGhJ2/4cDrl2t4iSbFLG1Aj7En23MFRnVlhg06WixWrCExPmJm1tPjQcxxrYA7Ll1PqGsU/DI4Hp8= X-Received: by 2002:a25:b00a:0:b0:d86:d285:14e7 with SMTP id q10-20020a25b00a000000b00d86d28514e7mr748606ybf.18.1695582159708; Sun, 24 Sep 2023 12:02:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Mon, 25 Sep 2023 00:32:03 +0530 Message-ID: Subject: Re: Invalidate the subscription worker in cases where a user loses their superuser status To: Amit Kapila Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, 23 Sept 2023 at 11:28, Amit Kapila wrote: > > On Sat, Sep 23, 2023 at 1:27=E2=80=AFAM vignesh C w= rote: > > > > > > Fixed this issue by checking if the subscription owner has changed > > from superuser to non-superuser in case the pg_authid rows changes. > > The attached patch has the changes for the same. > > > > @@ -3952,7 +3953,9 @@ maybe_reread_subscription(void) > newsub->passwordrequired !=3D MySubscription->passwordrequired || > strcmp(newsub->origin, MySubscription->origin) !=3D 0 || > newsub->owner !=3D MySubscription->owner || > - !equal(newsub->publications, MySubscription->publications)) > + !equal(newsub->publications, MySubscription->publications) || > + (!superuser_arg(MySubscription->owner) && > + MySubscription->isownersuperuser)) > { > if (am_parallel_apply_worker()) > ereport(LOG, > @@ -4605,6 +4608,13 @@ InitializeLogRepWorker(void) > proc_exit(0); > } > > + /* > + * Fetch subscription owner is a superuser. This value will be later > + * checked to see when there is any change with this role and the worker > + * will be restarted if required. > + */ > + MySubscription->isownersuperuser =3D superuser_arg(MySubscription->owne= r); > > Why didn't you filled this parameter in GetSubscription() like other > parameters? If we do that then the comparison of first change in your > patch will look similar to all other comparisons. I felt this variable need not be added to the pg_subscription catalog table, instead we could save the state of subscription owner when the worker is started and compare this value during invalidations. As this information is added only to the memory Subscription structure and not added to the catalog FormData_pg_subscription, the checking is slightly different in this case. Also since this variable will be used only within the worker, I felt we need not add it to the catalog. Regards, Vignesh