log level of "drop cascade" lists

On 1/10/19 3:28 AM, Willy-Bas Loos wrote:

Hi,

(this is in version 9.4)
The SQL command DROP schema myschema CASCADE tells me that the full list
of items that the drop cascades to is in the log, but it isn't.

messages on stdout:
...
drop cascades to table myschema.mytable
and 143 other objects (see server log for list)
DROP SCHEMA

The log doesn't mention this at all, except
2019-01-10 12:10:45 CET ERROR:  canceling autovacuum task
2019-01-10 12:10:45 CET CONTEXT:  automatic analyze of table
"myschema.mytable"

log_min_messages is on the default value, which is warning.
#log_min_messages = warning

At first glance, it seems logical that the list of dropped items is a
"notice". But now that it seems that the cascade went further than i
anticipated, it is of a greater significance to me than that.

Hence:

1) BEGIN;
DROP schema myschema CASCADE;
ROLLBACK/COMMIT;

2) \d myschema.*

Also, truncating the list in the message and referring to the log is not
desirable IMHO if the default  setting is to not log the list.

So long story short: i think it would be wise to set the log level of
"drop cascade" lists to "warning".

Cheers,
--
Willy-Bas Loos

--
Adrian Klaver
adrian.klaver@aklaver.com

Willy-Bas Loos <willybas@gmail.com> writes:

So long story short: i think it would be wise to set the log level of "drop
cascade" lists to "warning".

I think that would be met with more complaints than kudos.
"WARNING" is supposed to mean "there's probably something wrong here",
and a report of a cascaded drop is not that.

regards, tom lane

On Thu, Jan 10, 2019 at 4:44 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

1) BEGIN;
DROP schema myschema CASCADE;
ROLLBACK/COMMIT;

2) \d myschema.*

On Thu, Jan 10, 2019 at 5:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

I think that would be met with more complaints than kudos.
"WARNING" is supposed to mean "there's probably something wrong here",
and a report of a cascaded drop is not that.

OK, both are good points.
Since the list is truncated and possibly affects objects in other schemas,
I would recommend setting
SET log_min_messages = notice;
for that session (for anyone else reading this, no need to set it in the
settings file, the above is an sql command).
And then it is possible to view the full list in the log (e.g. after
rolling back the transaction with the drop query).

Cheers,
--
Willy-Bas Loos