Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwE5O-0007Y8-IE for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Feb 2019 22:41:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gwE5M-0001MO-Vh for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Feb 2019 22:41:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwE5M-0001J1-IF for pgsql-hackers@lists.postgresql.org; Tue, 19 Feb 2019 22:41:56 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwE5F-00023D-9E for pgsql-hackers@lists.postgresql.org; Tue, 19 Feb 2019 22:41:55 +0000 Received: by mail-qt1-x844.google.com with SMTP id z25so3429147qti.13 for ; Tue, 19 Feb 2019 14:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=0S6ek7WHTb/Nf26KrVljADKu+MO5fr3ubTeQX9oDzj0=; b=c6YUqyM1hoL9ByLxJ8muRLG5JVjIMwILZMMo5slRaSolA+XvWttqwr1cEpCRaeSuVv o+7wiqcr/BSizJK95rqH+aVvMziqwuWe0KNG1a9+kJAigdNbQ13X4Dy78HTKBcGEg0eo /LzGxusPQYjDl42Ma6++c3tJSwRtJEDC5AZA9UWEBG1Gtwx7XFyi5lG/fD0E8m8t4YHF N0SR6V1eNy0d8sRe07cRmz6sAC5Z6ItQvRpwWPktF9lQN1M8R3CJleX9iRrtUmFQN2ud 25abplRzjlVj/dMkJjmMHd/gxBJYb9IFDPWyWvip/tFNgrZjdfOkY9l+2qG5cA5/RYmW 6WQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=0S6ek7WHTb/Nf26KrVljADKu+MO5fr3ubTeQX9oDzj0=; b=lcfwQzc8tlpLyfqFTz6+UwNXZsV0Ican2BuI3LW8asgfwP2oo+ry2RtwVdlA7gon8P G/Fer9VbbLfeT98l4P9wIO40Zd7GPXpnRiw7XN3HCAfQkLb/LD/zarMar6bj2o+BLuwn 0CCTXs1rrLvfDB+PQLenN1XFft/7771vNg6oJEWcJV4tJnSGisJA7TBuoI69Hkf6Xhav YIYCNFckykwjHJ1gLDh71cqxPwnHf67RefQ3XWLBcjJvC+vtHrefxPX8syy7NW1lz12J nFpdRwZm8j/CoA3HKCtxEdTTUU9BV3r9Ugf6s8u4mFuWUBsf8ZeouLsQHF3g+KMx358i Wg9A== X-Gm-Message-State: AHQUAuYUnG+xRbLRn4/TZYuW5aOwWe3i+aHOnhxpmSM/CaBRNxtBQVbz gyNwCsiln/zw6H2Mvnf/DJb6IA== X-Google-Smtp-Source: AHgI3IaO0/I8ISKGCs32jybEL4s3vVcdgmZ+Bsnq0Azy251uzXvzPuTBDNsdiqBPL0ysfRFzug5G9w== X-Received: by 2002:ac8:1662:: with SMTP id x31mr24333011qtk.55.1550616107191; Tue, 19 Feb 2019 14:41:47 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([191.126.227.83]) by smtp.gmail.com with ESMTPSA id b22sm11294893qtc.23.2019.02.19.14.41.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Feb 2019 14:41:46 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 1BAC01246F4; Tue, 19 Feb 2019 19:41:40 -0300 (-03) Date: Tue, 19 Feb 2019 19:41:40 -0300 From: Alvaro Herrera To: Robert Haas Cc: Pg Hackers Subject: Re: propagating replica identity to partitions Message-ID: <20190219224140.GA14819@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Feb-19, Robert Haas wrote: > On Tue, Feb 19, 2019 at 3:40 PM Alvaro Herrera wrote: > > Maybe we should be using the inheritance marker in the command to note > > whether to recurse to partitions? That is, if you say > > ALTER TABLE ONLY parent SET REPLICA IDENTITY > > then we don't recurse and just change the parent table and future > > partitions, whereas if you leave out the ONLY then it does affect > > existing partitions. > > > > However, I think TABLESPACE and any other property that involves > > rewriting tables wholesale can reasonably be expected to behave > > differently (w.r.t. recursing) from commands that just modify the > > catalogs. I think we already have such a distinction somewhere. > > I don't really follow why that should be different, or why the user > should be expected to know or care whether a particular property > involves rewriting. OK, let me concede that point -- it's not rewriting that makes things act differently, but rather TABLESPACE (as well as some other things) behave that way. ALTER TABLE ... SET DATA TYPE is the obvious counterexample. The Notes section of ALTER TABLE says: : The actions for identity columns (ADD GENERATED, SET etc., DROP IDENTITY), as : well as the actions TRIGGER, CLUSTER, OWNER, and TABLESPACE never recurse to : descendant tables; that is, they always act as though ONLY were specified. : Adding a constraint recurses only for CHECK constraints that are not marked NO : INHERIT. Since REPLICA IDENTITY does not appear in this list, the documented behavior is to recurse, per the description of the "name" parameter: : The name (optionally schema-qualified) of an existing table to : alter. If ONLY is specified before the table name, only that table : is altered. If ONLY is not specified, the table and all its : descendant tables (if any) are altered. Optionally, * can be : specified after the table name to explicitly indicate that : descendant tables are included. I didn't come up with this on my own, as you imply. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services