forgot to say publish the Linux logs it may have more details what is going on
On Fri, Feb 21, 2020 at 12:27 PM Justin <zzzzz.g...@gmail.com> wrote: > is this happening from any client or just a specific client running ODBC? > are the clients running AV if so are the AV versions the same? > > Given this is killing a Linux server, sounds like ODBC is sending back > garabage data to the server crashing it. > > There are several settings in OBDC, to change how text columns are > processed, play around with those settings see if that helps it > https://odbc.postgresql.org/docs/config.html > > As you have it narrowed down to a table, try querying only a few records > at a time to see if you can identify the specific Record(s) that may be the > issue. > SELECT * FROM temptulemus where temptulemus.unique_id >1 offset 0 limit > 100 > > and try querying the columns that do not contain the suspect data that > could be causing this > > On Fri, Feb 21, 2020 at 12:01 PM Andrus <kobrule...@hot.ee> wrote: > >> Hi! >> >> >Realized I should have been clearer. By pre-libpq I meant this: >> >https://odbc.postgresql.org/docs/release.html >> >psqlODBC 09.05.0100 Release >> >Changes: >> > Use libpq for all communication with the server >> > Previously, libpq was only used for authentication. Using it for >> all >> > communication lets us remove a lot of duplicated code. libpq is now >> > required for building or using libpq. >> >> I upgraded psqlodbc driver to 12.1 version but problem persists. >> After server is manually started, application works. >> >> I added log_statement = 'all' . Log before crash is: >> >> 2020-02-21 18:46:40 EET mydbadmin mydb LOG: statement: SELECT >> drop_table('temptulemus') >> 2020-02-21 18:46:40 EET mydbadmin mydb LOG: statement: create temp table >> temptulemus as SELECT * FROM andmetp ;select * from temptulemus limit 0 >> 2020-02-21 18:46:40 EET mydbadmin mydb LOG: statement: select n.nspname, >> c.relname, a.attname, a.atttypid, t.typname, a.attnum, a.attlen, >> a.atttypmod, a.attnotnull, c.relhasrules, c.relkind, c.oid, >> pg_get_expr(d.adbin, d.adrelid), case t.typtype when 'd' then >> t.typbasetype >> else 0 end, t.typtypmod, c.relhasoids, '', c.relhassubclass from >> (((pg_catalog.pg_class c inner join pg_catalog.pg_namespace n on n.oid = >> c.relnamespace and c.oid = 28203181) inner join pg_catalog.pg_attribute a >> on >> (not a.attisdropped) and a.attnum > 0 and a.attrelid = c.oid) inner join >> pg_catalog.pg_type t on t.oid = a.atttypid) left outer join pg_attrdef d >> on >> a.atthasdef and d.adrelid = a.attrelid and d.adnum = a.attnum order by >> n.nspname, c.relname, attnum >> 2020-02-21 18:46:40 EET mydbadmin mydb LOG: statement: select >> COUNT(*)::int >> from temptulemus >> 2020-02-21 18:46:40 EET mydbadmin mydb LOG: statement: ;SELECT * FROM >> temptulemus offset 0 limit 900 >> 2020-02-21 18:46:40 EET LOG: server process (PID 6000) was terminated >> by >> exception 0xC0000005 >> 2020-02-21 18:46:40 EET HINT: See C include file "ntstatus.h" for a >> description of the hexadecimal value. >> 2020-02-21 18:46:40 EET LOG: terminating any other active server >> processes >> >> So command which causes crash is >> >> SELECT * FROM temptulemus offset 0 limit 900 >> >> As shown in lines before this is data from andmetp table. This table >> contains text type column. This column may contain data like <script> >> Maybe this causes postgres crash. Or maybe some unicode character in >> table >> cause crash. This table does not contain binary data. >> Database encoding is UTF-8. >> >> There is also other server in Linux >> >> PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled by gcc (Debian >> 4.9.2-10) >> 4.9.2, 64-bit >> >> which drops connection when reading the same table. Itlooks like in this >> case linux re-starts process automatically so application starts. >> Table contents are similar in both servers. >> >> Andrus. >> >> >> >>
