Re: How to fix 0xC0000005 exception in Postgres 9.0

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(dot)graf(at)gmail(dot)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 <kobruleht2(at)hot(dot)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.
>>
>>
>>
>>