Re: How to fix 0xC0000005 exception in Postgres 9.0
От | Adrian Klaver |
---|---|
Тема | Re: How to fix 0xC0000005 exception in Postgres 9.0 |
Дата | |
Msg-id | ef5a006a-6b89-8c48-abe2-2b950851c2c5@aklaver.com обсуждение исходный текст |
Ответ на | Re: How to fix 0xC0000005 exception in Postgres 9.0 ("Andrus" <kobruleht2@hot.ee>) |
Ответы |
Re: How to fix 0xC0000005 exception in Postgres 9.0
("Andrus" <kobruleht2@hot.ee>)
|
Список | 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 по дате отправления: