On 06.12.2018 11:52, Peter Geoghegan wrote:
On Wed, Dec 5, 2018 at 10:35 PM Andrey Lepikhov
<a.lepik...@postgrespro.ru> wrote:
This solution changes pg_depend relation for solve a problem, which
exists only in regression tests. Very rarely it can be in the
partitioning cases. Or is it not?
I don't think it's a matter of how rarely this will happen. We're
trying to avoid these diagnostic message changes because they are
wrong. I don't think that there is much ambiguity about that. Still,
it will happen however often the user drops objects belonging to
partition children, which could be quite often.
I want to say that we need to localize the rules for the order of the
diagnostic messages as much as possible in dependency.c.
I think this decision is some excessive.
May be you consider another approach:
1. Order of dependencies in 'DROP ... CASCADE' case is a problem of test
tools, not DBMS. And here we can use 'verbose terse'.
2. Print all dependencies in findDependentObjects() on a drop error (see
attachment as a prototype).
You didn't include changes to the regression test output, which seems
like a big oversight...
It was done knowingly to show the differences in messages that
introduces this approach.
messages that are represented in the regression tests. Anyway, I don't
think it's acceptable to change the messages like this. It makes them
much less useful.
May you clarify this? If I understand correctly, your solution is that
user receives a report about the last inserted internal dependency on
the object. Why the full info about internal dependencies of the object
much less useful?
These stability issue keeps coming up, which makes a comprehensive
approach seem attractive to me. At least 95% of the test instability
comes from pg_depend.
During the retail index tuple deletion project (heap cleaner subsystem)
we have non-fixed order of tuples at database relations. This caused to
unsteady order of text strings in some check-world test results.
Thus, I realized that the order of messages in the test results is
mostly a game of chance. For this reason I think it is necessary to find
more general solution of the messages ordering problem.
--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company
