Re: IO related waits - Mailing list pgsql-general

From Greg Sabino Mullane
Subject Re: IO related waits
Date
Msg-id CAKAnmmJhsNL=f+z7R018L6NrLQuq_7+quqZkGUKbzHRctHaY3w@mail.gmail.com
Whole thread Raw
In response to Re: IO related waits  (veem v <veema0000@gmail.com>)
Responses Re: IO related waits
Re: IO related waits
List pgsql-general
On Thu, Sep 19, 2024 at 5:17 AM veem v <veema0000@gmail.com> wrote:
2024-09-18 17:05:56 UTC:100.72.10.66(54582):USER1@TRANDB:[14537]:DETAIL:  Process 14537 waits for ShareLock on transaction 220975629; blocked by process 14548.

You need to find out exactly what commands, and in what order, all these processes are doing. Deadlocks can be avoided by rearranging your application logic.
 
2024-09-18 17:05:56 UTC:100.72.22.33(54582):USER1@TRANDB:[14537]:ERROR:  current transaction is aborted, commands ignored until end of transaction block
2024-09-18 17:05:56 UTC:100.72.22.33(54582):USER1@TRANDB:[14537]:STATEMENT:  INSERT INTO TRANDB.EXCEP_TAB (...)
2024-09-18 17:05:56 UTC:100.72.22.33(54582):USER1@TRANDB:[14537]:ERROR:  current transaction is aborted, commands ignored until end of transaction block
2024-09-18 17:05:56 UTC:100.72.22.33(54582):USER1@TRANDB:[14537]:STATEMENT:  
2024-09-18 17:05:56 UTC:100.72.22.33(36096):USER1@TRANDB:[14551]:ERROR:  current transaction is aborted, commands ignored until end of transaction block

Fix your application. It should be checking that each command completed and not just blindly pushing on to the next statement while ignoring the error.

This is really difficult to diagnose from afar with only snippets of logs and half-complete descriptions of your business logic. Pull everyone involved into a room with a whiteboard, and produce a document describing exactly what your application does, and how it is doing it. Switch from reactive to proactive.

Cheers,
Greg

pgsql-general by date:

Previous
From: Ron Johnson
Date:
Subject: Re: How batch processing works
Next
From: veem v
Date:
Subject: Re: IO related waits