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