Re: How to fix 0xC0000005 exception in Postgres 9.0 - Mailing list pgsql-general
| From | Justin |
|---|---|
| Subject | Re: How to fix 0xC0000005 exception in Postgres 9.0 |
| Date | |
| Msg-id | CALL-XeOAtrbxqqg0tKkcQCyw7aEzBDVXuCwLstOOShF7g=nZkQ@mail.gmail.com Whole thread Raw |
| In response to | Re: How to fix 0xC0000005 exception in Postgres 9.0 ("Andrus" <kobruleht2@hot.ee>) |
| Responses |
Re: How to fix 0xC0000005 exception in Postgres 9.0
(Justin <zzzzz.graf@gmail.com>)
|
| List | pgsql-general |
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
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 <kobruleht2@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.
pgsql-general by date: