Re: Materialized view rewrite is broken when there is an event trigger
От | Tom Lane |
---|---|
Тема | Re: Materialized view rewrite is broken when there is an event trigger |
Дата | |
Msg-id | 825329.1660055701@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Materialized view rewrite is broken when there is an event trigger (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Materialized view rewrite is broken when there is an event trigger
|
Список | pgsql-hackers |
Michael Paquier <michael@paquier.xyz> writes: > Please note that we should not add an event in create_am.sql even if > it is empty, as it gets run in parallel of other tests so there could > be interferences. I think that this had better live in > sql/event_trigger.sql, even if it requires an extra table AM to check > this specific case. Agreed this is a bug, but I do not think we should add the proposed regression test, regardless of where exactly. It looks like expending a lot of cycles forevermore to watch for an extremely unlikely thing, ie that we break this for ALTER MATERIALIZED VIEW and not anything else. I think the real problem here is that we don't have any mechanism for verifying that table_rewrite_ok is correct. The "cross-check" in EventTriggerCommonSetup is utterly worthless, as this failure shows. Does it give any confidence at all that there are no other mislabelings? I sure have none now. What can we do to verify that more rigorously? Or maybe we should find a way to get rid of the table_rewrite_ok flag altogether? regards, tom lane
В списке pgsql-hackers по дате отправления: