On Mon, Jun 01, 2020 at 10:49:25AM -0400, John Bachir wrote: > On Fri, May 29, 2020, at 10:10 PM, Justin Pryzby wrote: > > > If you do it right, you can see a DEBUG: > > postgres=# SET client_min_messages=debug; > > postgres=# ALTER TABLE tn ALTER i SET NOT NULL ; > > DEBUG: existing constraints on column "tn"."i" are sufficient to prove > > that it does not contain nulls > > Thanks! I'll add that to my recipe for the future. Although by that time it > would be too late, so to make use of this I would have to set up a cloned > test environment and hope that all conditions are correctly cloned. Is there > a way to check sufficiency before running the command?
Yea, client_min_messages is there to demonstrate that the feature is working and allow you to check whether it work using your own recipe. If you want to avoid blocking the table for nontrivial time, maybe you'd add: SET statement_timeout='1s'; On Mon, Jun 01, 2020 at 09:55:43PM -0400, John Bachir wrote: > > Maybe something else had a nontrivial lock on the table, and those commands > > were waiting on lock. If you "SET deadlock_timeout='1'; SET > > log_lock_waits=on;", then you could see that. > > Just checking - I think you mean lock_timeout? (although setting > deadlock_timeout is also not a bad idea just in case). No, actually (but I've had to double check): https://www.postgresql.org/docs/current/runtime-config-locks.html |When log_lock_waits is set, this parameter also determines the length of time |to wait before a log message is issued about the lock wait. If you are trying |to investigate locking delays you might want to set a shorter than normal |deadlock_timeout. -- Justin
