log level of "drop cascade" lists

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

log level of "drop cascade" lists

Willy-Bas Loos-3
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.
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
Reply | Threaded
Open this post in threaded view
|

Re: log level of "drop cascade" lists

Adrian Klaver-4
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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: log level of "drop cascade" lists

Tom Lane-2
In reply to this post by Willy-Bas Loos-3
Willy-Bas Loos <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: log level of "drop cascade" lists

Willy-Bas Loos-3

On Thu, Jan 10, 2019 at 4:44 PM Adrian Klaver <[hidden email]> wrote:

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

2) \d myschema.*

On Thu, Jan 10, 2019 at 5:04 PM Tom Lane <[hidden email]> 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