Fix writable rules on table has relative matview.

[avamingli]

Though rules are not well supported in GPDB, we have to update matview data status if there were.
Some SQL will generate like INSERT into another table which has relative matview.

Fix rules part issue of #582

Authored-by: Zhang Mingli avamingli@gmail.com

fix #ISSUE_Number

---

Change logs

Describe your change clearly, including what problem is being solved or what feature is being added.

If it has some breaking backward or forward compatibility, please clary.

Why are the changes needed?

Describe why the changes are necessary.

Does this PR introduce any user-facing change?

If yes, please clarify the previous behavior and the change this PR proposes.

How was this patch tested?

Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.

Contributor's Checklist

Here are some reminders and checklists before/when submitting your pull request, please check them:

• Make sure your Pull Request has a clear title and commit message. You can take git-commit template as a reference.
• Sign the Contributor License Agreement as prompted for your first-time contribution(One-time setup).
• Learn the coding contribution guide, including our code conventions, workflow and more.
• List your communication in the GitHub Issues or Discussions (if has or needed).
• Document changes.
• Add tests for the change
• Pass make installcheck
• Pass make -C src/test installcheck-cbdb-parallel
• Feel free to request cloudberrydb/dev team for review and approval when your PR is ready🥳

[reshke]

we can add additional checks inside answer_query_using_materialized_views, to check whether relation once had rules.
If so, disallow AQUMV.

Something like

bool
has_rules(Oid relationId)
{
	HeapTuple	tuple;
	bool		result;

	tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relationId));
	if (!HeapTupleIsValid(tuple))
		elog(ERROR, "cache lookup failed for relation %u", relationId);

	result = ((Form_pg_class) GETSTRUCT(tuple))->relhasrules;
	ReleaseSysCache(tuple);
	return result;
}

This way we will never get fooled by executor/gp_matview_aux related bugs.

[avamingli]

we can add additional checks inside answer_query_using_materialized_views, to check whether relation once had rules. If so, disallow AQUMV.

Something like

bool
has_rules(Oid relationId)
{
	HeapTuple	tuple;
	bool		result;

	tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relationId));
	if (!HeapTupleIsValid(tuple))
		elog(ERROR, "cache lookup failed for relation %u", relationId);

	result = ((Form_pg_class) GETSTRUCT(tuple))->relhasrules;
	ReleaseSysCache(tuple);
	return result;
}

This way we will never get fooled by executor/gp_matview_aux related bugs.

make sense.

[avamingli]

we can add additional checks inside answer_query_using_materialized_views, to check whether relation once had rules. If so, disallow AQUMV.
Something like

bool
has_rules(Oid relationId)
{
	HeapTuple	tuple;
	bool		result;

	tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relationId));
	if (!HeapTupleIsValid(tuple))
		elog(ERROR, "cache lookup failed for relation %u", relationId);

	result = ((Form_pg_class) GETSTRUCT(tuple))->relhasrules;
	ReleaseSysCache(tuple);
	return result;
}

This way we will never get fooled by executor/gp_matview_aux related bugs.

make sense.

Also think about triggers besides rules, though distributed triggers are not well supported in GPDB.
And sth like that may break AQUMV.
Will consider them in another pr.

[reshke]

I came up with another suggestion which worth a discussion. I propose to change this matview tracking algorithm from executor-based approach to TAM based one. That is, when relation data is modified (table_tuple_insert TAM method and similar), we mark all M.V. that depend on modified relation as stale(using gp_matview_tables).

This does not covers table inheritance cases though. So, table ihn related check should remain in place.

[avamingli]

I propose to change this matview tracking algorithm from executor-based approach to TAM based one. That is, when relation data is modified (table_tuple_insert TAM method and similar), we mark all M.V. that depend on modified relation as stale(using gp_matview_tables).

That's the my first drat approach, but it's more hard in MPP.
It requires each AM support, you may think to implement HEAP/AO/AOCS, but for other am extension which is easy to break.

The worse thing is, we use same kernel codes with CBDB in enterprise version using totally different AMs and different executors. If it's implemented in executor, other open source like Apache Arrow codes also need changed.

And the last, remember it's used for AQUMV, we don't have customers want to use inherits table to answer query.
It's hard to rewrite parse tree using inherits tables even you could maintain its data status.

Even though all that could be done well, it introduces more risk and no additional benefit.

[reshke]

It requires each AM support

Im not following why.
We can add code here for example. Before/after calling underlying method.

https://github.com/cloudberrydb/cloudberrydb/blob/978bab54358dc5331f9c7231aed38447f91f69f4/src/include/access/tableam.h#L1553-L1559
This will be TAM-unaware approach.

but it's more hard in MPP.

Yes, thats right. We are modifying data on QE whilst query planning is done on QD. So, we need to transfer knowledge between QE/QD. But turns out already have all pieces needed:

https://github.com/cloudberrydb/cloudberrydb/blob/978bab54358dc5331f9c7231aed38447f91f69f4/src/interfaces/libpq/fe-protocol3.c#L502-L513

Similar way we can send M.V.-invalidation messages from QE/QD

[reshke]

And the last, remember it's used for AQUMV, we don't have customers want to use inherits table to answer query. It's hard to rewrite parse tree using inherits tables even you could maintain its data status.

Sure, we should keep table inheritance restriction code in place.

I just trust executor much less that coding around TAM interfaces. This is more clear way IMO.

[reshke]

I can actually develop an PoC PR for this in my free time.

[avamingli]

We can add code here for example. Before/after calling underlying method.

If it's implemented in executor, other open source like Apache Arrow codes also need changed.

Other executor extensions do not call that am at all, all they need is a plan tree.

[reshke]

We can add code here for example. Before/after calling underlying method.

If it's implemented in executor, other open source like Apache Arrow codes also need changed.

Other executor extensions do not call that am at all, all they need is a plan tree.

understood.

[reshke]

Can we also traverse the plan and check for ModifyTable nodes? This will cover all cases except triggers.

[avamingli]

Can we also traverse the plan and check for ModifyTable nodes? This will cover all cases except triggers.

I'm not sure, we could discuss it when fix that then.