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 1mrmI0-00032U-Rc for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Nov 2021 19:26:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mrmHz-0004Dd-ME for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Nov 2021 19:26:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mrmHz-0004DU-9y for pgsql-hackers@lists.postgresql.org; Mon, 29 Nov 2021 19:26:11 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mrmHu-0002W8-8w for pgsql-hackers@postgresql.org; Mon, 29 Nov 2021 19:26:10 +0000 Received: by mail-pf1-x430.google.com with SMTP id r130so18019330pfc.1 for ; Mon, 29 Nov 2021 11:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=wJI0iIKBb5rRmr1778by0r9v/C9IllyL1T69F+jIYPs=; b=NN4M0f5TRTfT2Qf0lhiv/TLxjjYQ81RdXyVYigu2aRTtYXWDZNCTr2olfDxf6zdPho RgEJti8EeEAS6wojoBQm+/ZoccDApmZghfakxzY/FS280K30OHxNzTRmJSooL+ym/ZG9 Hu3LMhlvasK9kMtH+nOKIV7owIBHV5DwY3N9sJD3wSnCE34mzJ9HEVsCgTAtdvs1W/3U jLzycvaWXkIuNewH9Z2ks5p62ClEha52NQm53fBEvYNBTf0jmzbAu12dVfD5iHdkRns+ /5vzqIqnhO9oBEEx5C7sAtMHrj48PxZWPKjxspvKIOU/HlTLtCyRm4uSpA4Gfp8Jgu74 H28Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=wJI0iIKBb5rRmr1778by0r9v/C9IllyL1T69F+jIYPs=; b=Il0bAML7Oqxa4Uh1GIv8DRNcZSYgfDl2eIatsDguQURS2CwTQg1ogJRNtUYxZDL1k7 pEESR5qg1iGjk7DU/M0AWMpzPczcHXUmT8MOkFnnbMOEagf+watuzrO5+I4hYWLH8Xg8 uHqzxPv4CptIThsndfsCwXJ7HTgsNXMSL4jDFAQaN3AUxSAZbx57UCbzvW3qHwsS72Io TsWI6soxn/y+IVrdUXnmyXGk+3Ra1TgUMkLSX/r7+ndrJ7GcDH5d74vcySvin9zxhWBs 0/oVdH+KLaIqRDyZ/seVGdpJFmy8JQx8AKeCHSSW+4Xh7OWGiBn16gOPpPbMWvTJOdkW lumQ== X-Gm-Message-State: AOAM533qIiiWnOk9lUjQ/RjC+/Xf/y2bCBzT+smzIl2ktsTS7zLjqy7k KgvzaH2EM7GA+UWmWxyVqKiX+w== X-Google-Smtp-Source: ABdhPJyyVaq+lZyWoPCoIBkgGQNUpRhJva/JrDOfqkQ85lQA0bEOynNkkZ5RfzYP1wQqhyVa+ax10Q== X-Received: by 2002:a63:8948:: with SMTP id v69mr22404005pgd.524.1638213963648; Mon, 29 Nov 2021 11:26:03 -0800 (PST) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id k8sm10127887pfc.197.2021.11.29.11.26.02 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 29 Nov 2021 11:26:03 -0800 (PST) Message-ID: <785e8b8ab06f123cf754862557bd3171aeba4d65.camel@j-davis.com> Subject: Re: Non-superuser subscription owners From: Jeff Davis To: Amit Kapila Cc: Mark Dilger , Andrew Dunstan , PostgreSQL-development , Robert Haas Date: Mon, 29 Nov 2021 11:26:01 -0800 In-Reply-To: References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com> <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com> <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com> <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com> <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com> <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com> <18b267939a9d1ae27e9b3643d53395f4e29ea6ce.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote: > The first reason is that way it would be consistent with what we can > see while doing the operations from the backend. Logical replication is not interactive, so it doesn't seem quite the same. If you have a long running INSERT INTO SELECT or COPY FROM, the permission checks just happen at the beginning. As a user, it wouldn't surprise me if logical replication was similar. > operation. Another reason is to make behavior predictable as users > can > always expect when exactly the privilege change will be reflected and > it won't depend on the number of changes in the transaction. This patch does detect ownership changes more quickly (at the transaction boundary) than the current code (only when it reloads for some other reason). Transaction boundary seems like a reasonable time to detect the change to me. Detecting faster might be nice, but I don't have a strong opinion about it and I don't see why it necessarily needs to happen before this patch goes in. Also, do you think the cost of doing maybe_reread_subscription() per- tuple instead of per-transaction would be detectable? If we lock ourselves into semantics that detect changes quickly, it will be harder to optimize the per-tuple path later. Regards, Jeff Davis