On 13/07/15 16:21, Michael Matz wrote:
Hi,
On Mon, 13 Jul 2015, Tom de Vries wrote:
Implementing multi-step maps or making the hashmaps non-caching
doesn't solve any of the above problems
I'm not saying that making those hashmaps non-caching solves any of
these problems.
Ah, I didn't mean to imply this, I meant to imply that enforcing policy as
you do is a good thing because it finds bugs, and that the policy to be
enforced should be forbidding multi-step deps :)
I'm saying that it decouples fixing the policy (for which I have a
patch) from fixing the issues that allow us to use these 3 as caches
again (for which there are no patches yet). The advantage of having a
policy in place is that we won't regress for tables still marked as
cache (or new tables marked as cache). So blocking committing the policy
on those issues makes no sense IMHO.
That's right, I didn't argue for that either.
Great, we're in agreement then :)
But there should then be at
least a PR with a patch that disables the work-arounds for policy breakers
(the three decl-debug hash-maps), that if applied breaks bootstrap, so
that the fact that there's still a real bug somewhere doesn't get lost.
Yep, there should be a PR to track these issues.
And I made the down-grades for each cache a single patch, to make it
easy to revert once we fix all the issues for one table.
Now let's see if I can get approval for "Don't mark live recursively in
gt_cleare_cache".
Thanks,
- Tom
