Re: How to fix 0xC0000005 exception in Postgres 9.0 - Mailing list pgsql-general

From Adrian Klaver
Subject Re: How to fix 0xC0000005 exception in Postgres 9.0
Date
Msg-id ef5a006a-6b89-8c48-abe2-2b950851c2c5@aklaver.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  ("Andrus" <kobruleht2@hot.ee>)
List pgsql-general
On 2/21/20 10:24 AM, Andrus wrote:
> Hi!
> 
>> forgot to say publish the Linux logs it may have more details what is 
>> going on
> 
> Linux server has older application client which replicates all data one 
> from andmetp table using select * from andmetp
> I tried several times. Linux log contains
> 
> 2020-02-21 16:18:50 EET mydbadmin mydb STATEMENT:  SELECT * FROM andmetp
> 2020-02-21 16:18:50 EET mydbadmin mydb FATAL:  connection to client lost
> 2020-02-21 16:18:50 EET mydbadmin mydb STATEMENT:  SELECT * FROM andmetp
> 2020-02-21 17:19:08 EET mydbadmin mydb LOG:  could not send data to 
> client: Connection reset by peer
> 2020-02-21 17:19:08 EET mydbadmin mydb STATEMENT:  SELECT * FROM andmetp
> 2020-02-21 17:19:08 EET mydbadmin mydb FATAL:  connection to client lost
> 2020-02-21 17:19:08 EET mydbadmin mydb STATEMENT:  SELECT * FROM andmetp
> 
> It looks like only connection was terminated.  “dmesg -T” does not show 
> postgres crash. Maybe postgres main process is not killed in Linux.
> 
>> is this happening from any client or just a specific client running ODBC?
> 
> This happene if Windows 2008 server if logged in same same server from 
> RDP client and in my development windows 10 workstation which logs to 
> linux server over VPN
> 
>> are the clients running AV if so are the AV versions the same?
> 
> In windows 2008 server antivirus was turned off like I wrote.  In my 
> devel workstation I use Microsoft antivirus coming with windows 10.
> 
>> Given this is killing a Linux server,  sounds like ODBC is sending  
>> back garabage data to the server crashing it.
> 
> I can try publish odbc log if this helps.
> 
> Application replicateds some tables at startup to local disk.
> For tables with 5000 or more rows odbc connection hangs if there is big 
> TCP packet loss.
> So we changed  replication command
> 
> select * from mytable
> 
> to commands
> 
> select drop_table(‘temptulemus’);
> create temp table  tempestuous as select * from mytable;
> 
> select * from mytable offset 0 limit 900;
> select * from mytable offset 900 limit 900;
> select * from mytable offset 1800 limit 900;
> ...
> 
> etc.
> 
> In this case data was also retrieved on poor connections.
> Maybe there is some better solution for this.
> 
>> 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
> 
> Application needs certain settings. Maybe it is better try to upgrade to 
> Postgres 12.2 first.
> 
>> 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
> 
> andmetp table contains 584 record in linux server. I tried script to 
> read data from this table every time one more row


In psql what does \d tempestuous show?

What relation is andmetp to tempestuous?

I thought you said you had problem with same table in Linux and Windows 
servers?

 From above what does the drop_table() function do in?:

select drop_table(‘temptulemus’);

> 
> for i=1 to 600
> ? i
> StartTextMerge()
> TEXT TEXTMERGE NOSHOW
> select * from andmetp limit <<tran(i)>>
> ENDTEXT
> IF !TExec()
>   RETURN .f.
>   ENDIF
> endfor
> 
> this worked without error.
> 
> Andrus.


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: "Andrus"
Date:
Subject: Re: How to fix 0xC0000005 exception in Postgres 9.0
Next
From: Michael Lewis
Date:
Subject: Re: Logical replication lag in seconds