PostgreSQL Error like “canceling statement due to statement timeout” – I love this error message because the developer should know the tentative require total execution time of their queries or functions.

In a real-time application, we must analyze the average execution time for our queries so that System Admin or Database Admin can allocate resource workload appropriately.

I completely disagree with Developers for arguments like why we need to inform tentative execution time of our query?.

Because for example, today you execute your query and it took two mins so tomorrow, it might complete in around two mins only.

For this query, we can set timeout up to 5 mins, but if it is taking more than 5 mins, then the developer should check for that query.

So error like “canceling statement due to statement timeout” which helps a lot to identify this kind of long running query.

If your query starts to take more time, there are mainly two reasons:
1. Query is same, but the number of records increases in table
2. DBA forget to execute VACUUM ANALYZE or ANALYZE

So here my suggestion is, DBA can set a timeout value for mission critical query or we can also set threshold value so that we can check the status of a query before killing it.

In PostgreSQL, you can set the statement_timeout parameter at the Server level or Session level.
For server level, we have to modify PostgreSQL.conf file and for session level we can use below statement.

set statement_timeout = '60 s'; -- 60 seconds

Timeout:

When the client application is waiting for a require resource, Timeout occurs.

There are multiple reasons for Timeout like transaction blocking, the distance network, high CPU utilization and multiple request user request at one time.

The Database Timeout cannot affect to other running connection, and it treated independently, but for solving the Timeout issue we need to check other causes like OS response, Network response, Database Timeout threshold value, number of Database Connections and other.

Lock:

When one process is accessing an object, it can request for a lock for that particular object so that other processes cannot perform read or update on that object.

There are different types of lock like Exclusive Lock, Non-exclusive Lock.

An Exclusive Lock prevents object or data from the reading and writing both the actions.
A Non-Exclusive Lock allows read-only access for an object or data, but it prevents the write action for an object or data.

Block:

If two processes are accessing the same resource so at that time one process has to wait until the other process releases the occupied resource.

This is called blocking because one transaction is blocked by another transaction and all blocked processes kept in the waiting queue.

If the blocked transaction is waiting for a long time, it may generate a Database Timeout.
If the long-running blocked transaction requires a lock, it may generate a Database Deadlock.

Deadlock:

One X process is waiting to complete the transaction of the Y process, and the same time, Y process is blocked because it is also waiting to complete the transaction of the X process.
This is called as Deadlock situation.

In the Deadlock situation, both the processes trying to access a particular resource and also has a lock on that resource by each other, so both are waiting for each other to release a lock and complete the transaction.

Deadlock is a next stage of the blocking situation so if you want to avoid Deadlock situation, you should first find the blocked transaction and tried to remove internal dependency for those transactions.