Closed achix closed 1 week ago
FALSE ALERT! it was just a matter of freetds debugging .. One user could could write to /tmp/freetds.log the others not.
Please follow this thread : https://www.postgresql.org/message-id/flat/f43721f9-e628-4a22-b84d-e0ccc75b50cc%40cloud.gatewaynet.com
Issue report
The following information is very important in order to help us to help you. Omission of the following details cause delays or could receive no attention at all.
Operating system
On recent GNU/Linux distributions, you can provide the content of the file
/etc/os-release
Version of tds_fdw
From a
psql
session, paste the outputs of running\dx
If you built the package from Git sources, also paste the output of running
git log --source -n 1
on your git clone from a consoleVersion of PostgreSQL
From a
psql
session, paste the output of runningSELECT version();
Version of FreeTDS
How to get it will depend on your Operating System and how you installes FreeTDS
From a console:
rpm -qa|grep freetds
dpkg -l|grep freetds
grep 'AC_INIT' configure.ac
_Logs
Please capture the logs when the error you are reporting is happening, as well as commands with their outputs if you are reporting a problem build or installing
_For problems using tdsfdw on PostgreSQL how to do it will depend on your system, but if your PostgreSQL is installed on GNU/Linux, you will want to use
tail -f
with the log of the PostgreSQL clusterFor MSSQL you will need to use the SQL Server Audit Log
Sentences, data structures, data
This will depend on the exact problem you are having and data privacy restrictions
However the more data you provide, the more likely we will be able to help
As a bare minimum, you should provide
Now the problem , in the new system it runs more than 10 times slower than the old. New System (pgsql16) :
old system (pgsql10) :
For the duration that the slow query (pgsql 16) runs, the backend process hits 100% of its CPU.