On Wed, Jul 03, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> 29.06.2024 05:42, Noah Misch wrote:
> > Good point, any effort on (2) would be wasted once the fixes get certified. I
> > pushed (1). I'm attaching the rebased fix patches.
>
> Please look at a new anomaly, introduced by inplace110-successors-v5.patch:
> CREATE TABLE t (i int) PARTITION BY LIST(i);
> CREATE TABLE p1 (i int);
> ALTER TABLE t ATTACH PARTITION p1 FOR VALUES IN (1);
> ALTER TABLE t DETACH PARTITION p1;
> ANALYZE t;
>
> triggers unexpected
> ERROR: tuple to be updated was already modified by an operation triggered by the current command
Thanks. Today, it's okay to issue heap_inplace_update() after heap_update()
without an intervening CommandCounterIncrement(). The patch makes the CCI
required. The ANALYZE in your example reaches this with a heap_update to set
relhassubclass=f. I've fixed this by just adding a CCI (and adding to the
tests in vacuum.sql).
The alternative would be to allow inplace updates on TM_SelfModified tuples.
I can't think of a specific problem with allowing that, but I feel that would
make system state interactions harder to reason about. It might be optimal to
allow that in back branches only, to reduce the chance of releasing a bug like
the one you found.