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 1qgA5K-00Edlg-Kt for pgsql-bugs@arkaria.postgresql.org; Tue, 12 Sep 2023 20:34:10 +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 1qgA5I-00AQB8-Cb for pgsql-bugs@arkaria.postgresql.org; Tue, 12 Sep 2023 20:34:08 +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.94.2) (envelope-from ) id 1qgA5H-00AQAu-V6 for pgsql-bugs@lists.postgresql.org; Tue, 12 Sep 2023 20:34:07 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qgA5A-004D0p-DF for pgsql-bugs@postgresql.org; Tue, 12 Sep 2023 20:34:06 +0000 Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1bf57366ccdso1703895ad.1 for ; Tue, 12 Sep 2023 13:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1694550839; x=1695155639; darn=postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Utv5VqKidM0/vUlxDKwh/Sr0SuwN48mQkrdcZvtPkrE=; b=UI6R24yvogSBe8ZOeCJ/xh0Bw+MCJEbVxlLCBvSCYNjO/5f0pbw2cjBTLXhyw5FcoL WyFOwrrjbwGOjyXi4wbWKzYyj0Qs3XABmpUPYySRWblmGRVGrVPhg4w/c+muLX4ctBbQ uONCXnwxveQZ1lutD9QsCcTMCWh7LM9VU2UqXyxYSiDRnMkMLglvElzzcbYAoDpA20jA YgYe3KZqpuABoODwdj1bYlJ0JCPaemCTUcar4VIS4O9uYNb5f3HcIHBE07tRFMIWt5J7 XEGhZ0641yGrSWnhr6WMA599ytnGQzywTGYQrf92qOhdAtpe3rycqEOpK3NTDLPqV6AW tolQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694550839; x=1695155639; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Utv5VqKidM0/vUlxDKwh/Sr0SuwN48mQkrdcZvtPkrE=; b=Fd/uHEx7vkGpjwrljfmULkgoQ5GzaY3cNXqN+mtZzyKQ2xpvo0hkSmi116wd/sm4i9 KTKeVro9ACMHd4yavUbcd5gREHz73zNnJDSBf2OakRjQfS00Key80dCvD/30I0G+k8vp 9M6P5IfDS2PRt7aKHIzG2SZ3NuX8hzlbyMPmeTA5i6B2gaJCOF8AVkrmcM8jNxNR13X9 4KFBJnL69cor4g744XJ5G4iysYbUEnZkAVdXktJPa5cVRhg/rwJb7cazuwDeai/EmwgS xPVpnGV0PHB0FJNqMeEp05k17aU7Xl999xzkDnnBJ5ZihtnxIFF0irJiP2cmhCOMFiwJ nQFw== X-Gm-Message-State: AOJu0Yx2nViFoH/kWMdunQaRaIa5T+RtbVKpO5C5I8/K5sTKVMXTVnKi 9ccgcPepy5hBfsS35cusKEZWdg== X-Google-Smtp-Source: AGHT+IHoWpWXRFaa8R5nZKfbTqhkmzt/tNX1775Tz5t1+/O0u+W6EljPmyeN5TbEA3u+xtFg7npqIg== X-Received: by 2002:a17:90b:4b02:b0:267:f8f4:73ab with SMTP id lx2-20020a17090b4b0200b00267f8f473abmr4803288pjb.16.1694550839282; Tue, 12 Sep 2023 13:33:59 -0700 (PDT) Received: from [172.18.5.16] ([12.126.244.130]) by smtp.gmail.com with ESMTPSA id q10-20020a170902daca00b001bdca6456b9sm8972164plx.17.2023.09.12.13.33.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 13:33:58 -0700 (PDT) Message-ID: <163428cd3f4bb3894ae86ed3278f320442ec41e1.camel@j-davis.com> Subject: Re: [16+] subscription can end up in inconsistent state From: Jeff Davis To: Amit Kapila Cc: pgsql-bugs@postgresql.org, Robert Haas Date: Tue, 12 Sep 2023 13:33:57 -0700 In-Reply-To: References: <5dff4caf26f45ce224a33a5e18e110b93a351b2f.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2023-09-12 at 16:13 +0530, Amit Kapila wrote: > Do we want to remove > that as anyway, we will do that check via walrcv_connect()? I think we should keep the DDL-time checks in place as a best-effort, but not rely on them for security. > Another point is that if we want to unify such a check at the time of > walrcv_connect() then do we need to do it at the time of Alter > Subscription? I think it will probably be better to catch the problem > early Agreed. Catching mistakes at DDL time is a better user experience. > but does removing it from Alter Subscription time and doing it > at connect time lead to security hazards? We'd still be doing the same check, just later, right? If so there's not a big security risk in removing the DDL-time checks. But it's probably not a good idea to have non-superuser-owned subscriptions without a password specified, so there may be some hazard there. >=20 Regards, Jeff Davis