On Wed, Jan 17, 2024 at 3:48 PM Tender Wang <tndrwang@gmail.com> wrote:Hmm, thanks for the report.I can repeat the aboved issue on master, even on pg10 and pg 11.I analyzed this issue, and I found that ATExecAddColumn(), we forgot to call CommandCounterIncrement() in if (colDef->inhcount > 0) {...} branch.So the third(a->d) updates the first(a->b->c->d) tuple.Attached patch is my quickly fixed solution.Indeed. We may update the same child column multiple times, but thereis no CommandCounterIncrement between. Nice catch and +1 to the fix.To nitpick, how about go with the comment as /* Make sure the child column change is visible */which seems clearer.Also I think it'd be better to include a blank line before and after thenew CommandCounterIncrement statement.Also I suggest to drop the new added tables after we've run ALTER TABLEin the test case.ThanksRichard
Hmm, thanks for the report.I can repeat the aboved issue on master, even on pg10 and pg 11.I analyzed this issue, and I found that ATExecAddColumn(), we forgot to call CommandCounterIncrement() in if (colDef->inhcount > 0) {...} branch.So the third(a->d) updates the first(a->b->c->d) tuple.Attached patch is my quickly fixed solution.
pgsql-bugs by date:
Соглашаюсь с условиями обработки персональных данных