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 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. 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 is orthogonal to what you were addressing before, but I'm just wondering what you think). Thanks, John
