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 1gqh92-0003QG-Jh for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Feb 2019 16:30:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gqh91-0004Ir-E6 for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Feb 2019 16:30:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqh90-0004IQ-UD for pgsql-hackers@lists.postgresql.org; Mon, 04 Feb 2019 16:30:51 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqh8w-0002Zb-68 for pgsql-hackers@lists.postgresql.org; Mon, 04 Feb 2019 16:30:49 +0000 Received: by mail-ed1-x541.google.com with SMTP id y56so357479edd.11 for ; Mon, 04 Feb 2019 08:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :content-transfer-encoding:user-agent; bh=Xj+ZqJVcQSYX/zLVFo2C17U4+5+zh3w/fr0zvehNZmU=; b=fgyuAREILmLw6FBcemIfeNBT5Xo2aUvsH5b6gSvqgRfq/4r5LuUs3U8MKcJStV94Uo /bkKWJxB9sZWczS0KpNRWZc8+AABBAbEN9a5VRGlybjZY/AaLWZ0sRYUqTn1br8EnmQQ dajqwDwisPov97Q8o36BHB9ylDCatN5/Gr1rqsfYbZ2sCxM2NG3mLYtoSIJgPD+tK9A4 ylHd6xSo7oX/4F37MEkf3Yp5GJkbIynVQ33qGPTgNfZ1flPFDnzhH/a138AKTC0t713u j/ARLgo4TG2l0ZKJyaefNGmzIuTAgbjt192md6q17jkwhhmpf8LrawEluucVEZhhodbs 3RxA== 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:subject:message-id:mime-version :content-disposition:content-transfer-encoding:user-agent; bh=Xj+ZqJVcQSYX/zLVFo2C17U4+5+zh3w/fr0zvehNZmU=; b=UijigBFCNEaSKBDrrWOkajVMKLswU7TEoI07Shl6E+38LhjQv25a+VXRsMMYLIS6B6 zW8hKIeyvKc6+/X/wVz2V64+kH1/kDDwM+NM4kt4cKeU7aFzZmwwTfkx7Cb9EA2h0IQY JGnYOn3I3T+5koxTb7PEXzhvls6oPk/HBz+QMDoFq9p7fb4E9E8g8alNtLqKLZQIXlfx +Uq+TCe9r+NChuEksJ1F7C8SZTYHzAxbh0B8mxO65QFHewf0P8EN1XkxDN1WFzFex/H4 I0awzmHVr3QPewaWz++WIn4nqWDJ3Zhyuz2W+KK0aN62p/P9QNdstNXGDwV4Ewp1mD+S iCuQ== X-Gm-Message-State: AHQUAuYT7HytKl0toP/GxfR9Xje9W9Ta0qfflaxYOjuOU2CfSINNojGC Wi3/wyJ7BvD0GqnGzTMCDKYCINot2ZbCJLb1c2xHjYeDqstfvAJ1GgugyNBkYo27xh95fyfzxXr eG5t7QSmGH0VsunU16CrHCTYFSxfnYhKofrSYtpsOevX/SrZISGAY/FPut6ly2sbm8R+71FrG4w vzW1Pz6Ve1TyJ4CvD5 X-Google-Smtp-Source: AHgI3IbukaUERh8A25tgjx4Ecm3nG3d0eNlk1FEJX2NzC5gFQGmgcA4ScNANEYzn+asf3w97zaKTIQ== X-Received: by 2002:a50:875d:: with SMTP id 29mr198309edv.100.1549297843469; Mon, 04 Feb 2019 08:30:43 -0800 (PST) Received: from alvin.alvh.no-ip.org (104.142-201-80.adsl-dyn.isp.belgacom.be. [80.201.142.104]) by smtp.gmail.com with ESMTPSA id f20sm4595594edf.19.2019.02.04.08.30.42 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Feb 2019 08:30:42 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id E83436D1; Mon, 4 Feb 2019 13:30:41 -0300 (-03) Date: Mon, 4 Feb 2019 13:30:41 -0300 From: Alvaro Herrera To: Pg Hackers Subject: propagating replica identity to partitions Message-ID: <201902041630.gpadougzab7v@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: NeoMutt/20180716-1013-2c1e88 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello If you do ALTER TABLE .. REPLICA IDENTITY to a partitioned table, the command operates on the parent table itself and does not propagate to partitions. Why is this? Maybe not recursing was the right call when we only had regular inheritance (back in 9.4), but since partitioned tables got introduced, I think it is completely the other way around: not recursing is an usability fail. At the same time, I think that psql failing to display the replica identity for partitioned tables is just an oversight and not designed in. I propose to change the behavior to: 1. When replica identity is changed on a partitioned table, all partitions are updated also. Do we need to care about regular inheritance? My inclination is not to touch those; this'd become the first case in ATPrepCmd that recurses on partitioning but not inheritance. 2. When a partition is created, the replica identity is set to the same that the parent table has. If it's type index, figure out the corresponding index in the partition, set that. If the index doesn't exist, raise an error (i.e. replica identity cannot be set to an index until it has propagated to all children). 3. psql should display replica identity for partitioned tables. Thoughts? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services