From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |
Date: | 2018-12-06 06:52:30 |
Message-ID: | CAH2-WznYm9bTi1N1+wTAK=cXTuH23oxFtPqpT_7kYGqS5Xdutw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 5, 2018 at 10:35 PM Andrey Lepikhov
<a(dot)lepikhov(at)postgrespro(dot)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 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, given that this has a lot to do with diagnostic
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.
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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Mithun Cy | 2018-12-06 06:55:25 | Re: zheap: a new storage format for PostgreSQL |
Previous Message | Ron | 2018-12-06 06:48:09 | Re: Limitting full join to one match |