Andres Freund <[email protected]> writes:
> On 2019-10-10 16:51:23 -0400, Tom Lane wrote:
>> Do you *really* need an event trigger to test this?
> No. I added it to avoid the tests getting "accidentally" optimized away,
> the next time somebody adds some ALTER TABLE optimizations. The fast
> default stuff had removed coverage from a test that'd have uncovered
> this bug. And an event trigger seemed to be the easiest way to achieve
> that.
> The only real alternative I can see to just removing the trigger is
> embedding a check in the trigger that will cause it to only work in the
> current session. Something like SET regress.log_table_rewrites, and a
> IF current_setting('regress.log_table_rewrites')::bool in the function.
If you just want to verify that a rewrite happened or didn't happen,
seems like you could check whether the table's relfilenode changed.
regression=# select relfilenode as oldfilenode from pg_class where relname =
'rewrite_test'
regression-# \gset
regression=# select relfilenode != :oldfilenode as changed from pg_class where
relname = 'rewrite_test';
changed
---------
f
(1 row)
regression=# alter table rewrite_test alter column notempty3_norewrite type
bigint;
ALTER TABLE
regression=# select relfilenode != :oldfilenode as changed from pg_class where
relname = 'rewrite_test';
changed
---------
t
(1 row)
I really really don't want an event trigger running in everything that
runs in parallel with alter_table. That's a debugging nightmare of
monster proportions.
regards, tom lane
