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.96) (envelope-from ) id 1vfUwC-002J0s-26 for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 03:19:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfUwB-002Yny-2m for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 03:19:20 +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.96) (envelope-from ) id 1vfUwB-002Ynq-1g for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 03:19:19 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfUw9-0008tW-10 for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 03:19:19 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-38305f05717so45543791fa.1 for ; Mon, 12 Jan 2026 19:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768274351; x=1768879151; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j5dY+WtGHOcijpZ9asGRrP3mMuROIrzSBOb6g02TWtE=; b=eYvc1fBSn3ptVvduATbQy0zTdmkV5PbL8F6pT6s7w6UyNoUEZzlb/u2NJGpMxA5Qew 9HxfydHiKn1/cEKDNkoC/gBTXOdriQo/eMd2gU3IbUL3l6wsfKzGk/dxIPlKgy3HGMP5 Q+qxqFj6FVtIwmzBv4p1amVvWzM5WkzJujYEnLqKib7vwJF0vcblz5AN1UzM8dSo3H0M EtqJm8Taqrt4eKfjj+UjkMnMTTx1L/R6otaF9shsPwQPL+B0CRNOaGB8KJQA+9nVVQK3 T3Pv1qWmmjanShCcuzQ4M+dfOOuNbfzX93mOcE/GZ5LMYt4rA+Pjd3Xg+sHp6LqqSbA0 aWfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768274351; x=1768879151; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j5dY+WtGHOcijpZ9asGRrP3mMuROIrzSBOb6g02TWtE=; b=HQkwsKqT+tThPZ4p8E8LXO3Kp/2c8+g3LlPAszVNP1usDT2mAVYv7kdhjoESjKHlbv JUaTyx30xSHw25kkVOOygPnSHetVfYRRaz9E96OFLeYve16fHyDGfkv5xaeKyYdiI+Li 7rij7PRaUzdp0rjeURqGCawM9X4X6wC5VKGpi01mVmEkOtjKysz8eRQaW8lle6u1fXSA gAgFGSXfnMa1Ly6PxEwXiwcjRSosenycfX2/85duFS9IvM5zfXX1+tvqNpnj/v+rnWva JfD/mzB5MLaBqythndteuT6q7saB+U4fFMIia9nKXd+E/+3+hWAmxjGVF3bkShNNQFpi 57Ow== X-Gm-Message-State: AOJu0YyqY9FLfYyPHSbW1MQd5PtqULt1XCEWTI2bn4nHdcKjTgLw+wnB Cqj3Ud+XVfHcSqgMnPqDeulRDdnIac2S42vo/yiUA1VzlKKj2skQOE6lvCZBTtnbrdqjmwRyOlQ mZ81jixnaNQ4n6z8bN4jVH2dPONRHhYc= X-Gm-Gg: AY/fxX5ZHrQxp3eDBU7B1VxTpGBmeemW8WLvQYwej/ZqFzjNbMClwARQf9InwcIbzE2 U43Gnand21PMK+Lm7r5XC6PBDDdlbBQOJPbzC42HypVZxqH0cEM9SsBrfdbmXxaYBHxXnfP5VYe H5tyim8crNQXZcxshKodRa214g/4s3J61kw6F8ra13v3M4JfClbPbNzuXnv6mHt8/l/tMR5DfFE 3B8DiKUV/eFiWvWBnzPhSqVno4i2QYd5yW3Idr+nDcHr2/ksd1wUjHRe8sK+f+A18aU4WD0 X-Google-Smtp-Source: AGHT+IEMP0/GN394MNLU0T2rHazs4shf3NYDMk0OPX59oTPvQEq86HW4WPLvn0nwf7lAXsl4eU3BPA+0ZGQPwOF94M0= X-Received: by 2002:a05:651c:221d:b0:383:20cd:530d with SMTP id 38308e7fff4ca-38320cd5619mr40131191fa.7.1768274351184; Mon, 12 Jan 2026 19:19:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chao Li Date: Tue, 13 Jan 2026 11:18:58 +0800 X-Gm-Features: AZwV_QgEgEOidOQcg7cBqu0dbeLvX-yzOrRhsKEQuXYfBrgJ_4JPF28_41Umy_c Message-ID: Subject: Re: ALTER TABLE: warn when actions do not recurse to partitions To: "David G. Johnston" , Greg Sabino Mullane Cc: Postgres hackers Content-Type: multipart/mixed; boundary="000000000000918c3106483c74c0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000918c3106483c74c0 Content-Type: multipart/alternative; boundary="000000000000918c2f06483c74be" --000000000000918c2f06483c74be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David and Greg, Thanks a lot for your reviews and feedbacks. On Jan 12, 2026, at 22:40, David G. Johnston wrote: On Monday, January 12, 2026, Chao Li wrote: For now, I=E2=80=99ve limited the change to REPLICA IDENTITY to see whether= there are objections to this approach. If there are none, I plan to extend the same warning behavior to the other sub-commands listed above. After that, users can reasonably assume that an ALTER TABLE partitioned_table ... action will recurse to child partitions unless a warning explicitly tells them otherwise. It should be a notice, not a warning. Make sense. I changed to NOTICE in v2. How about indicating how many partitions were affected in the notice and I added partition count in the notice message in v2. allowing the absence of such a notice to be the indicator that cascading did not happen? David J. I don=E2=80=99t think relying on the absence of a notice works well in this= case. Currently, cascading never happens, which is exactly why I=E2=80=99m adding= a NOTICE. If we rely on silence to indicate =E2=80=9Cno cascade=E2=80=9D, use= rs have no signal that their expectation was incorrect. The ALTER TABLE documentation says: ``` 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. ``` Given this, users reasonably expect that omitting ONLY will cause REPLICA IDENTITY to cascade to partitions. In reality, it never does, which breaks that expectation. The NOTICE is intended to make this behavior explicit in exactly that case. On Jan 12, 2026, at 23:23, Greg Sabino Mullane wrote: On Mon, Jan 12, 2026 at 9:40=E2=80=AFAM David G. Johnston < david.g.johnston@gmail.com> wrote: How about indicating how many partitions were affected in the notice and allowing the absence of such a notice to be the indicator that cascading did not happen? I like the idea of number of partitions, but think we need to be more explicit than people surmising the lack of a notice is significant. Cheers, Greg As explained above, the NOTICE is only emitted in the case where the documented ALTER TABLE semantics suggest cascading, but REPLICA IDENTITY does not actually cascade to partitions. This makes the behavior explicit, rather than relying on users to infer meaning from the absence of a message= . PSA v2: * Changed level log to NOTICE * Rephrased the notice message and included partition count in the message. Now, the message is like: ``` evantest=3D# alter table sensor_data replica identity full; NOTICE: REPLICA IDENTITY does not apply to partitions (1 affected) ALTER TABLE ``` Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/ --000000000000918c2f06483c74be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
H= i David and Greg,

Thanks a lot for your reviews and feed= backs.

On Jan 12, 2026, at 22:40, David G. Johnston <david.g.johnst= on@gmail.com> wrote:

On Monday, January 12, 2026, Chao Li <= ;li.evan.chao@g= mail.com> wrote:

For now, I=E2=80=99ve limited the change to= =C2=A0REPLICA IDENTITY=C2=A0to see whether there are objections to this app= roach. If there are none, I plan to extend the same warning behavior to the= other sub-commands listed above. After that, users can reasonably assume t= hat an=C2=A0ALTER TABLE partitioned_table ...=C2=A0action will recurse to c= hild partitions=C2=A0unless=C2=A0a warning explicitly tells them otherwise.=

It should be a notice, not a warning.

Make sense. I changed to NOTICE in v2.


How about indicating how many partitions were affected in the not= ice and

I added partition count in the not= ice message in v2.

allowing the absence = of such a notice to be the indicator that cascading did not happen?

= David J.


I don=E2=80=99t think rely= ing on the absence of a notice works well in this case.

Currently, cascading never happens, which is exactly why I=E2=80=99m = adding a NOTICE. If we rely on silence to indicate =E2=80=9Cno cascade=E2= =80=9D, users have no signal that their expectation was incorrect.

The ALTER TABLE documentation says:
```
If=C2=A0ONLY=C2=A0is specified before the table name, only that tab= le is altered. If=C2=A0ONLY=C2=A0is not specified, the table and all its de= scendant tables (if any) are altered.
```

Given this, users reasonably expect that omitting ONLY will cause RE= PLICA IDENTITY to cascade to partitions. In reality, it never does, which b= reaks that expectation. The NOTICE is intended to make this behavior explic= it in exactly that case.


On Jan 12, 2026, at 23:23, Greg Sabino Mullane &= lt;htamfids@gmail.c= om> wrote:

On Mon, Jan 12, 2026 at 9:40=E2=80=AFAM David G. J= ohnston <david.g.johnston@gmail.com> wrote:
How about indicating how many= partitions were affected in the notice and allowing the absence of such a = notice to be the indicator that cascading did not happen?

I like the= idea of number of partitions, but think we need to be more explicit than p= eople surmising the lack of a notice is significant.

Cheers,
Greg=

As explained above, the NOTICE = is only emitted in the case where the documented ALTER TABLE semantics sugg= est cascading, but REPLICA IDENTITY
does not actually cascade to = partitions. This makes the behavior explicit, rather than relying on users = to infer meaning from the absence of a message.

<= div>PSA v2:

* Changed level log to NOTICE
* Rephrased the notice message and included partition count in the messag= e.

Now, the message is like:
```
evantest=3D# alter table sensor_data replica identity full;
NOTICE: =C2=A0REPLICA IDENTITY does not apply to partitions (1 affected)=
ALTER TABLE
```

Best re= gards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/




--000000000000918c2f06483c74be-- --000000000000918c3106483c74c0 Content-Type: application/octet-stream; name="v2-0001-Add-notice-when-ALTER-TABLE-REPLICA-IDENTITY-does.patch" Content-Disposition: attachment; filename="v2-0001-Add-notice-when-ALTER-TABLE-REPLICA-IDENTITY-does.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mkc0vjhv0 RnJvbSAyZmIyNTc4ZWZjNzRkYmY5MDI3Y2EwZjY1ZTQxNzFhZDRkNmQ5NjRjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiAiQ2hhbyBMaSAoRXZhbikiIDxsaWNAaGlnaGdvLmNvbT4KRGF0 ZTogTW9uLCAxMiBKYW4gMjAyNiAxNjo1Njo1OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggdjJdIEFk ZCBub3RpY2Ugd2hlbiBBTFRFUiBUQUJMRSBSRVBMSUNBIElERU5USVRZIGRvZXMgbm90CiByZWN1 cnNlCgpBTFRFUiBUQUJMRSAuLi4gUkVQTElDQSBJREVOVElUWSBhY2NlcHRzIGEgcmVjdXJzaXZl IGZvcm0gb24KcGFydGl0aW9uZWQgdGFibGVzLCBidXQgdGhlIGNoYW5nZSBpcyBhcHBsaWVkIG9u bHkgdG8gdGhlIHBhcnRpdGlvbmVkCnRhYmxlIGl0c2VsZiBhbmQgZG9lcyBub3QgcHJvcGFnYXRl IHRvIGNoaWxkIHBhcnRpdGlvbnMuCgpQcmV2aW91c2x5IHRoaXMgY2FzZSB3YXMgc2lsZW50bHkg YWNjZXB0ZWQsIHdoaWNoIGNvdWxkIG1pc2xlYWQgdXNlcnMKaW50byBhc3N1bWluZyB0aGF0IHRo ZSBzZXR0aW5nIHdvdWxkIHJlY3Vyc2UuIEFkZCBhIG5vdGljZSB3aGVuCnJlY3Vyc2lvbiBpcyBy ZXF1ZXN0ZWQgb24gYSBwYXJ0aXRpb25lZCB0YWJsZSB0byBtYWtlIHRoZSBiZWhhdmlvcgpleHBs aWNpdCBhbmQgYXZvaWQgY29uZnVzaW9uLgoKVGhpcyBjaGFuZ2UgZG9lcyBub3QgYWx0ZXIgc2Vt YW50aWNzOyBpdCBvbmx5IHByb3ZpZGVzIHVzZXItdmlzaWJsZQpmZWVkYmFjay4gU2ltaWxhciBu b3RpY2VzIG1heSBiZSBhZGRlZCBmb3Igb3RoZXIgQUxURVIgVEFCTEUKc3ViLWNvbW1hbmRzIHdp dGggbm9uLXJlY3Vyc2l2ZSBiZWhhdmlvciBpbiBmb2xsb3ctdXAgY29tbWl0cy4KCkF1dGhvcjog Q2hhbyBMaSA8bGljQGhpZ2hnby5jb20+Ci0tLQogc3JjL2JhY2tlbmQvY29tbWFuZHMvdGFibGVj bWRzLmMgfCAyOCArKysrKysrKysrKysrKysrKysrKysrKy0tLS0tCiAxIGZpbGUgY2hhbmdlZCwg MjMgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2Vu ZC9jb21tYW5kcy90YWJsZWNtZHMuYyBiL3NyYy9iYWNrZW5kL2NvbW1hbmRzL3RhYmxlY21kcy5j CmluZGV4IGY5NzZjMGU1YzdlLi4yZThkNzY5MDY1YyAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQv Y29tbWFuZHMvdGFibGVjbWRzLmMKKysrIGIvc3JjL2JhY2tlbmQvY29tbWFuZHMvdGFibGVjbWRz LmMKQEAgLTY5Myw3ICs2OTMsNyBAQCBzdGF0aWMgdm9pZCBkcm9wX3BhcmVudF9kZXBlbmRlbmN5 KE9pZCByZWxpZCwgT2lkIHJlZmNsYXNzaWQsIE9pZCByZWZvYmppZCwKIAkJCQkJCQkJICAgRGVw ZW5kZW5jeVR5cGUgZGVwdHlwZSk7CiBzdGF0aWMgT2JqZWN0QWRkcmVzcyBBVEV4ZWNBZGRPZihS ZWxhdGlvbiByZWwsIGNvbnN0IFR5cGVOYW1lICpvZlR5cGVuYW1lLCBMT0NLTU9ERSBsb2NrbW9k ZSk7CiBzdGF0aWMgdm9pZCBBVEV4ZWNEcm9wT2YoUmVsYXRpb24gcmVsLCBMT0NLTU9ERSBsb2Nr bW9kZSk7Ci1zdGF0aWMgdm9pZCBBVEV4ZWNSZXBsaWNhSWRlbnRpdHkoUmVsYXRpb24gcmVsLCBS ZXBsaWNhSWRlbnRpdHlTdG10ICpzdG10LCBMT0NLTU9ERSBsb2NrbW9kZSk7CitzdGF0aWMgdm9p ZCBBVEV4ZWNSZXBsaWNhSWRlbnRpdHkoUmVsYXRpb24gcmVsLCBSZXBsaWNhSWRlbnRpdHlTdG10 ICpzdG10LCBib29sIHJlY3Vyc2UsIExPQ0tNT0RFIGxvY2ttb2RlKTsKIHN0YXRpYyB2b2lkIEFU RXhlY0dlbmVyaWNPcHRpb25zKFJlbGF0aW9uIHJlbCwgTGlzdCAqb3B0aW9ucyk7CiBzdGF0aWMg dm9pZCBBVEV4ZWNTZXRSb3dTZWN1cml0eShSZWxhdGlvbiByZWwsIGJvb2wgcmxzKTsKIHN0YXRp YyB2b2lkIEFURXhlY0ZvcmNlTm9Gb3JjZVJvd1NlY3VyaXR5KFJlbGF0aW9uIHJlbCwgYm9vbCBm b3JjZV9ybHMpOwpAQCAtNTIyNyw4ICs1MjI3LDE1IEBAIEFUUHJlcENtZChMaXN0ICoqd3F1ZXVl LCBSZWxhdGlvbiByZWwsIEFsdGVyVGFibGVDbWQgKmNtZCwKIAkJCUFUU2ltcGxlUGVybWlzc2lv bnMoY21kLT5zdWJ0eXBlLCByZWwsCiAJCQkJCQkJCUFUVF9UQUJMRSB8IEFUVF9QQVJUSVRJT05F RF9UQUJMRSB8IEFUVF9NQVRWSUVXKTsKIAkJCXBhc3MgPSBBVF9QQVNTX01JU0M7Ci0JCQkvKiBU aGlzIGNvbW1hbmQgbmV2ZXIgcmVjdXJzZXMgKi8KLQkJCS8qIE5vIGNvbW1hbmQtc3BlY2lmaWMg cHJlcCBuZWVkZWQgKi8KKworCQkJLyoKKwkJCSAqIFRoaXMgY29tbWFuZCBub3cgZG9lc24ndCBy ZWN1cnNlLCBidXQgd2Ugd2FudCB0byBub3RpZnkgdXNlciBpZgorCQkJICogcmVjdXJzZSBpcyBz ZXQKKwkJCSAqCisJCQkgKiBObyBjb21tYW5kLXNwZWNpZmljIHByZXAgbmVlZGVkCisJCQkgKi8K KwkJCWlmIChyZWN1cnNlKQorCQkJCWNtZC0+cmVjdXJzZSA9IHRydWU7CiAJCQlicmVhazsKIAkJ Y2FzZSBBVF9FbmFibGVUcmlnOgkJLyogRU5BQkxFIFRSSUdHRVIgdmFyaWFudHMgKi8KIAkJY2Fz ZSBBVF9FbmFibGVBbHdheXNUcmlnOgpAQCAtNTY0Myw3ICs1NjUwLDggQEAgQVRFeGVjQ21kKExp c3QgKip3cXVldWUsIEFsdGVyZWRUYWJsZUluZm8gKnRhYiwKIAkJCUFURXhlY0Ryb3BPZihyZWws IGxvY2ttb2RlKTsKIAkJCWJyZWFrOwogCQljYXNlIEFUX1JlcGxpY2FJZGVudGl0eToKLQkJCUFU RXhlY1JlcGxpY2FJZGVudGl0eShyZWwsIChSZXBsaWNhSWRlbnRpdHlTdG10ICopIGNtZC0+ZGVm LCBsb2NrbW9kZSk7CisJCQlBVEV4ZWNSZXBsaWNhSWRlbnRpdHkocmVsLCAoUmVwbGljYUlkZW50 aXR5U3RtdCAqKSBjbWQtPmRlZiwKKwkJCQkJCQkJICBjbWQtPnJlY3Vyc2UsIGxvY2ttb2RlKTsK IAkJCWJyZWFrOwogCQljYXNlIEFUX0VuYWJsZVJvd1NlY3VyaXR5OgogCQkJQVRFeGVjU2V0Um93 U2VjdXJpdHkocmVsLCB0cnVlKTsKQEAgLTE4NTE1LDEyICsxODUyMywyMiBAQCByZWxhdGlvbl9t YXJrX3JlcGxpY2FfaWRlbnRpdHkoUmVsYXRpb24gcmVsLCBjaGFyIHJpX3R5cGUsIE9pZCBpbmRl eE9pZCwKICAqIEFMVEVSIFRBQkxFIDxuYW1lPiBSRVBMSUNBIElERU5USVRZIC4uLgogICovCiBz dGF0aWMgdm9pZAotQVRFeGVjUmVwbGljYUlkZW50aXR5KFJlbGF0aW9uIHJlbCwgUmVwbGljYUlk ZW50aXR5U3RtdCAqc3RtdCwgTE9DS01PREUgbG9ja21vZGUpCitBVEV4ZWNSZXBsaWNhSWRlbnRp dHkoUmVsYXRpb24gcmVsLCBSZXBsaWNhSWRlbnRpdHlTdG10ICpzdG10LCBib29sIHJlY3Vyc2Us IExPQ0tNT0RFIGxvY2ttb2RlKQogewogCU9pZAkJCWluZGV4T2lkOwogCVJlbGF0aW9uCWluZGV4 UmVsOwogCWludAkJCWtleTsKIAorCWlmIChyZWN1cnNlICYmIHJlbC0+cmRfcmVsLT5yZWxraW5k ID09IFJFTEtJTkRfUEFSVElUSU9ORURfVEFCTEUpCisJeworCQlQYXJ0aXRpb25EZXNjIHBkID0g UmVsYXRpb25HZXRQYXJ0aXRpb25EZXNjKHJlbCwgdHJ1ZSk7CisJCWludAkJCW5wYXJ0cyA9IHBk LT5ucGFydHM7CisKKwkJZXJlcG9ydChOT1RJQ0UsCisJCQkJKGVycm1zZygiUkVQTElDQSBJREVO VElUWSBkb2VzIG5vdCBhcHBseSB0byBwYXJ0aXRpb25zICglZCBhZmZlY3RlZCkiLAorCQkJCQkJ bnBhcnRzKSkpOworCX0KKwogCWlmIChzdG10LT5pZGVudGl0eV90eXBlID09IFJFUExJQ0FfSURF TlRJVFlfREVGQVVMVCkKIAl7CiAJCXJlbGF0aW9uX21hcmtfcmVwbGljYV9pZGVudGl0eShyZWws IHN0bXQtPmlkZW50aXR5X3R5cGUsIEludmFsaWRPaWQsIHRydWUpOwotLSAKMi4zOS41IChBcHBs ZSBHaXQtMTU0KQoK --000000000000918c3106483c74c0--