Re: feature idea: use index when checking for NULLs before SET NOT NULL
От | John Bachir |
---|---|
Тема | Re: feature idea: use index when checking for NULLs before SET NOT NULL |
Дата | |
Msg-id | 58edef30-6858-4740-97a4-9c6e2b7f332b@www.fastmail.com обсуждение исходный текст |
Ответ на | Re: feature idea: use index when checking for NULLs before SET NOTNULL (Justin Pryzby <pryzby@telsasoft.com>) |
Список | pgsql-hackers |
Thank you Justin for all that useful info! A couple nitpicky questions, so I can get my recipe right. On Mon, Jun 1, 2020, at 10:04 PM, Justin Pryzby wrote: > On Mon, Jun 01, 2020 at 10:49:25AM -0400, John Bachir wrote: > > 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 thisI would have to set up a cloned test environment and hope that all conditions are correctly cloned. Is there a way tocheck 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. Gotcha. Okay, just to double-check - you are saying there is _not_ a way to check before running the command, right? > > 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. Hah! Unexpected and useful. I think to avoid blocking my application activity, I should _also_ set lock_timeout, and retry if it fails. (maybe this isorthogonal to what you were addressing before, but I'm just wondering what you think). Thanks, John
В списке pgsql-hackers по дате отправления: