Better way to handle suppression of CASCADE detail messages
In various places in the regression tests, we want to suppress DROP
CASCADE's detail messages because of the fact that they don't always
come out in the same order. I noticed that some places deal with that
by adjusting client_min_messages while others use "\set VERBOSITY terse".
I think that the latter approach is superior, because with it you still
get to see the basic notice message, something like
NOTICE: drop cascades to 17 other objects
In this way, the test at least verifies that the expected number of
objects get dropped, even if we aren't checking their precise identities.
So, barring objection, I'm going to run around and change all the tests
that use client_min_messages for this purpose to use VERBOSITY instead.
BTW, in the long run maybe we should instead make the CASCADE message
ordering more predictable, perhaps by sorting the objects by OID.
But that's not a job for beta time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2017-08-01 13:34:45 -0400, Tom Lane wrote:
BTW, in the long run maybe we should instead make the CASCADE message
ordering more predictable, perhaps by sorting the objects by OID.
But that's not a job for beta time.
Oid is probably not good enough - with parallel tests and such it's not
necessarily predicable. Even less so when the tests are run against an
existing cluster. Sorting by name would probably be better...
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund <andres@anarazel.de> wrote:
Oid is probably not good enough - with parallel tests and such it's not
necessarily predicable. Even less so when the tests are run against an
existing cluster. Sorting by name would probably be better...
It's arguably more user-friendly, too, although part of me feels like
it would be better to try to preserve the topological ordering in some
way. If something cascades to foo and from there to bar and from
there to baz to and from there to quux, emitting the messages as
drop cascades to bar
drop cascades to baz
drop cascades to foo
drop cascades to quux
is arguably not going to be too helpful to the user in understanding
the chain of events, however nice it may be for regression testing
purposes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund <andres@anarazel.de> wrote:
Oid is probably not good enough - with parallel tests and such it's not
necessarily predicable. Even less so when the tests are run against an
existing cluster. Sorting by name would probably be better...
It's arguably more user-friendly, too, although part of me feels like
it would be better to try to preserve the topological ordering in some
way.
Yeah, loss of the causality relationship is the main thing that's bugging
me too.
If we sorted by OID then in most cases the objects would be listed in
creation order, which would likely also have something to do with the
dependency order; but it would be different in the same cases that are
most likely to be confusing :-(
I do not buy Andres' concern about parallelism breaking the test results.
We only ever drop objects created in the same test, so their OID ordering
would be the same (ie creation order) in every case unless an OID
wraparound occurred mid-test, which isn't a situation I feel a need to
worry about for this purpose. However, possible loss of user friendliness
*is* a valid concern here.
Anyway, we don't need a design for this today.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-08-01 13:48:34 -0400, Robert Haas wrote:
On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund <andres@anarazel.de> wrote:
Oid is probably not good enough - with parallel tests and such it's not
necessarily predicable. Even less so when the tests are run against an
existing cluster. Sorting by name would probably be better...It's arguably more user-friendly, too, although part of me feels like
it would be better to try to preserve the topological ordering in some
way. If something cascades to foo and from there to bar and from
there to baz to and from there to quux, emitting the messages asdrop cascades to bar
drop cascades to baz
drop cascades to foo
drop cascades to quuxis arguably not going to be too helpful to the user in understanding
the chain of events, however nice it may be for regression testing
purposes.
I'm not sure that's going to easily be better - won't the oid order in
turn determine the topological order. Which then again isn't very easy
to understand for users.
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund wrote:
On 2017-08-01 13:48:34 -0400, Robert Haas wrote:
On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund <andres@anarazel.de> wrote:
Oid is probably not good enough - with parallel tests and such it's not
necessarily predicable. Even less so when the tests are run against an
existing cluster. Sorting by name would probably be better...It's arguably more user-friendly, too, although part of me feels like
it would be better to try to preserve the topological ordering in some
way. If something cascades to foo and from there to bar and from
there to baz to and from there to quux, emitting the messages asdrop cascades to bar
drop cascades to baz
drop cascades to foo
drop cascades to quuxis arguably not going to be too helpful to the user in understanding
the chain of events, however nice it may be for regression testing
purposes.I'm not sure that's going to easily be better - won't the oid order in
turn determine the topological order. Which then again isn't very easy
to understand for users.
I'm not sure I buy the idea of ordering by name. Not all objects are
going to be of the same type, so ordering by name is going to look
strange.
OID order would only have a problem if you run the tests just before OID
wraparound, and the counter wraps in the middle of the test. To me that
seems a fringe enough situation that we shouldn't worry about it ... in
a freshly initdb'd cluster it will never behave strangely.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers