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
Iwould have to set up a cloned test environment and hope that all conditions are correctly cloned. Is there a way to
checksufficiency 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