Skip to content

pqFlush() — connection not open

ISSUE:
pqFlush() — connection not open

CAUSE:
This error is written to pg.log when user sesisons gets timed out. One of the possible cause is that the users max query limit is reached.

REOSLUTION:
Check the max query ttimeout set for the user by running below query.

SYSTEM(ADMIN)=> select USERNAME, SESSIONTIMEOUT, QUERYTIMEOUT from _v_user where username like ‘user123′;
USERNAME | SESSIONTIMEOUT | QUERYTIMEOUT
———-+—————-+————–
user123 | 120 | 60
(1 row)

Like, above example says the query will timeout is user123 run a query which will not finish in 60 minutes.

Then check psotgres logs to verify that this user query ran for 60 moniutes and then failed with above error.

Now, you need to identify if his user is running a legitmate query and if this user needs to run this query then possibly you may have to increase the query timeout limit.

SPU swap partition – Disk temporary work space is full

ERROR:
SPU swap partition : Disk temporary work space is full

CAUSE:
This error does not mean that we have a space issue on any of our dta slices but ratehr this error means that the maximum temporary workspace is full. This workspace is used by all the temporary tables, sorting and/or data skew. This can also occur if the query have cartesian joins (i.e. unresolved M::M relationships), causing the temporary workspace to grow out of control.

RESOLUTION:
Based on the above causes you cna try one or all of the below option.
1) Verify if the tables involved in the query have high skew. If yes then try to remove skew by re-distrubiting the table with appropiate distribution key.
2) Try to drop the temporary tables once they are not needed in the session.
3) Try to run lesser number of concurent jobs with thise heavy query which is eating up all the temporary disk space.
4) Try to rewrite the query more efficiently by avoiding cartesion joins if possible.

Run nz_spu_swap_space support script to find the current usage of SPU swap space.