Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
От | Andrey Lepikhov |
---|---|
Тема | Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) |
Дата | |
Msg-id | 3294d285-d3b3-e159-b3f7-6c2d1b059956@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
|
Список | pgsql-hackers |
On 06.12.2018 11:52, Peter Geoghegan wrote: > On Wed, Dec 5, 2018 at 10:35 PM Andrey Lepikhov > <a.lepikhov@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
В списке pgsql-hackers по дате отправления: