There is a Query that keeps timing out exactly after 30 seconds. I have seen a few posts on Stackoverflow which are similar to the issue i'm facing, the only thing that makes my issue different is that, i'm not using a DSN-LESS Connection, I'm using ODBC ADMINISTRATOR.
The following Error is the error i'm receiving:
16:33:16.06 System.Data.Odbc.OdbcException (0x80131937): ERROR [57014] ERROR: canceling statement due to statement timeout;
I guess my question is, how can i go about increasing the connection timeout using ODBC Administrator ?
Any help would be appreciated
You can try to run in each database session something similar to:
postgres=# set statement_timeout='300s';
SET
postgres=# show statement_timeout;
statement_timeout
-------------------
5min
(1 row)
postgres=#
To avoid doing this in each database session it would be easier to change this parameter in postgresql.conf: the new setting would be enabled for all database sessions.
Related
I have a Postgres installed in a Centos and another application is using Postgres the save data.
For sometime, and I can't find the reason, all the database tables become empty on the weekends.
I have been searching a lot to try to find some clues of the reason of that behaviour, but logs are not giving me that info.
I am pretty sure the application is not executing anything to clean the records, my thoughts are pointing to some process for some reason in the Postgres side.
The pg_log only shows this warning the day it happens:
HINT: Consider increasing the configuration parameter "checkpoint_segments".
LOG: checkpoints are occurring too frequently (11 seconds apart)
Apart from that I have no other clues.
Performing a VACUUM ANALYZE VERBOSE it says there is no dead data so it has nothing to delete.
Can you tell me what should I look to get the reason? Should it be any Postgres process to do it?
LOG: checkpoints are occurring too frequently (11 seconds apart)
This log message should also include all the information log_line_prefix tells it to include. So you should set log_line_prefix to include more information, like application name (voluntarily supplied by the client), database username, and host name/IP from which the connection came.
But perhaps more directly at issue, if things are connecting to your database and doing things you don't understand or approve of, it is time to change your passwords.
I have very starnge behavior on Azure PostgreSQL server.
I try to read DB size using the next query:
SELECT CAST(pg_database_size(current_database()) * 1.0/(1024 * 1024) AS DECIMAL(12, 5))
But this query runs very long and I have timeout exception in my C# application:
Exception while reading from stream; Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I have no idea why pg_database_size takes a lot of time...
To resolve my problem I see two options:
Increase query performance using Azure PostgreSQL Server settings
Replace the current query to another query with some result
I'm open for any suggestions.
Please give me any ideas about how I can read DB size fast and correctly.
Here is very much the same sql, runs fine directly on postgresql
SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database; --- as option #2 ?
I am facing the below issue
ERROR: canceling statement due to user request
inconsistently after I enabled query timeout for xa datasource in my xxx-ds.xml. I have added the following in my ds xml file.
<query-timeout>180</query-timeout>
The query timeout is set for 180 seconds, which means any sql query
that takes more than 180 seconds will get cancelled from application
server side.
But the issue I am facing is inconsistent and the queries gets timed out now and then without taking exactly 180 seconds.
We are using connection pooling also.
While searching stackoverflow found this question, which discusses about the possible causes for this issue while using connection pooling.
The solution suggested there was to set statement_timeout setting in postgresql.conf file. But it is bit difficult for me to enable statement_timeout setting in my database environment as the DB server is shared by multiple applications.
I would like to have a solution to terminate timed out queries from client side effectively and consistently while using connection pooling. I am using
JBoss 4.2.2-GA
postgresql 9.2 (64 bit)
java 1.7
postgresql-9.2-1002.jdbc4.jar
It looks like the issue is with postgresql driver 9.2. When I upgraded to 9.3, issue is fixed.
I have been working in SAS connecting to DB2 via ODBC for a while now and this PROC SQL step generally works:
proc sql;
connect to odbc(dsn=DSQ user="UserID" password="Password");
execute (set current degree = 'ANY' ) by ODBC;
create table tempTable as select * from connection to odbc (
select *
from schemaName.tableName
);
quit;
However, occassionally I get the following error, and when I get this error I won't be able to run another ODBC query for quite some time because everytime I try to run the query I get the same error:
ERROR: CLI error trying to establish connection: [IBM][CLI Driver] SQL1042C An unexpected system
error occurred. SQLSTATE=58004
After some time the error either resolves itself or I do something that I am not aware of that fixes the issue. This is a very frustrating issue and since I never know how long this issue is going to persist I would like a more robust solution to this issue. I have checked the db2diag.log file and here is the part that describes this error:
2015-06-03-08.17.34.345000-300 I60888H446 LEVEL: Error
PID : 4452 TID : 7804 PROC : sas.exe
INSTANCE: DB2 NODE : 000
HOSTNAME:
EDUID : 7804
FUNCTION: DB2 Common, Cryptography, cryptDynamicLoadGSKitCrypto, probe:998
MESSAGE : ECF=0x90000007=-1879048185=ECF_UNKNOWN
Unknown
DATA #1 : unsigned integer, 4 bytes
60
DATA #2 : String, 11 bytes
gsk8sys.dll
I was trying to find an example to put in this post so I ran this snippet of code in SAS to see if the error would come back, however it seemed to have resolved the error because after running this piece of code, I ran the initial code and it worked. Here is the code that seemed to have resolved the issue.
proc sql;
connect to odbc(dsn=DSQ user="UserID" password="Password");
execute (set current degree = 'ANY' ) by ODBC;
create table column_names as select * from connection to odbc (
select * from sysibm.syscolumns
);
quit;
I have tried googling this issue, but there isn't much help on this particular error. Is there any reason that the second SAS code would have fixed the issue I was having? Is there any way to fix this problem so it won't come back in the future?
Please note, when the error occurs, I am still able to run queries via ODBC in Microsoft Access without any problems. It appears this is an issue with just a particular instance.
System Setup:
Windows 7 64-bit
SAS 9.3 (32)
DB2 v10.5.300.125
Thanks in advance for your help!
Update:
On a few occasions, I was able to go into task manager and delete some processes that were still running and then this issue would resolve itself, however today when this problem occurred, those processes weren't there. Any thoughts on this would be greatly appreciated.
The symptom may be depended on the installation order of Db2 connect and a program (sas.exe). If DB2 connect is installed first, it should not be occurred. So it is suggested to remove and re-install both products once then install Db2 connect first.
Hope this helps.
I'm trying to run a Drupal migration via SSH and drush (a command line shell), copying data from a postgres database to mysql.
It works fine for a while (~5 mins or so), but then I get the error:
SQLSTATE[HY000]: General error: 7 SSL [error] SYSCALL error: EOF detected
The postgres database connection seems to have gone, and I just get errors:
SQLSTATE[HY000]: General error: 7 no [error] connection to the server
It works fine locally, so I think the problem must be with postgres and running a script over SSH - but googling these errors returns nothing useful. Does anyone know what could be causing this?
Could be a timeout. first inspect the log (maybe change ssl_renegotiation_limit)
BTW: IIRC, the renegotiation does not take place after a fixed amount of time, but after a certain amount of transmitted characters (2GB?)
You should check both your PostgreSQL and MySQL logs for further potential details. If there's not much in the PostgreSQL log, look at the log_min_error_statement in postgresql.conf. As you'll find through that link, you can tune it to increase the amount of logging. If there's still not clues in the PostgreSQL log, I would look at other components in your system for the problem.