Given errors like the pair you posted, my next step would be to examine the queries being executed by those processes during the deadlock. Now, I think by the time the deadlock error is logged, the queries involved have been cancelled, so it's possible the processes have gone on to another query and so pg_stat_activity might not have useful information, or it might--depending on what your app would do after a deadlock error. If it does not, then the next thing would be to set log_min_duration_statement to less than deadlock/statement timeout, so that you could look through logs to figure out what are the two queries which are deadlocking against each other. -- Scott Ribe scott_ribe@xxxxxxxxxxxxxxxx https://www.linkedin.com/in/scottribe/ > On Aug 14, 2024, at 9:38 PM, Wasim Devale <wasimd60@xxxxxxxxx> wrote: > > Ok thanks for the insights. > Do we need to do any config changes in the config file? > We have also configured Datadog agent at operating system level that checks postgresql activity it's has the pgpouncer.d config file that is unchanged after the migration. This might be the possible reason that it is throughing dead lock error. > Please through some insights on the above. > Thanks for the immediate help. > Regards, > Wasim > > On Thu, 15 Aug, 2024, 9:01 am David G. Johnston, <david.g.johnston@xxxxxxxxx> wrote: > On Wednesday, August 14, 2024, Wasim Devale <wasimd60@xxxxxxxxx> wrote: > So it's not a postgresql issue. It's from the application side correct? > > That’s the assumption. The vast majority of locks happen because the “application” executed SQL commands. > > David J.
