On 2/22/20 3:28 PM, Ron wrote:
On 2/22/20 5:12 PM, Adrian Klaver wrote:
On 2/22/20 2:39 PM, Andrus wrote:
[snip]
This is a different issue and involves a product VFP that is EOL 5-10
years depending on support package. I'm going to say the hand writing
is on the wall and it is time to upgrade
Greetings,
* Ron (ronljohnso...@gmail.com) wrote:
> Breaking userland backwards compatibility is a mortal sin, and one of the
> reasons that MS software is so popular is that they work so hard to *not*
> break userland backwards compatibility.
It's also a reason why it's a mess and not everyone i
> On Feb 22, 2020, at 4:28 PM, Ron wrote:
>
> On 2/22/20 5:12 PM, Adrian Klaver wrote:
>> On 2/22/20 2:39 PM, Andrus wrote:
> [snip]
>> This is a different issue and involves a product VFP that is EOL 5-10 years
>> depending on support package. I'm going to say the hand writing is on the
>
On 2/22/20 5:12 PM, Adrian Klaver wrote:
On 2/22/20 2:39 PM, Andrus wrote:
[snip]
This is a different issue and involves a product VFP that is EOL 5-10
years depending on support package. I'm going to say the hand writing is
on the wall and it is time to upgrade software.
I don't know where
On 2/22/20 2:39 PM, Andrus wrote:
Hi!
I have no idea.
I changed application not to send ; before select.
This solves issues in both servers.
So using ; as first character before select in ODBC command like
;SELECT * from mytable
Causes C5 is Postgres 9.0 and ODBC client hangup with "connec
Hi!
I have no idea.
I changed application not to send ; before select.
This solves issues in both servers.
So using ; as first character before select in ODBC command like
;SELECT * from mytable
Causes C5 is Postgres 9.0 and ODBC client hangup with "connection reset by
peer" message in log
On 2/21/20 11:43 PM, Andrus wrote:
Hi!
To me the relevant part of the log is below. Not sure what it means
though:
[3604-0.187] execute.c[Exec_with_parameters_resolved]444:
stmt_with_params = ';SELECT * FROM temptulemus offset 0 limit 900'
[3604-0.187] execute.c[Exec_with_parameters_resolved]4
Hi!
To me the relevant part of the log is below. Not sure what it means though:
[3604-0.187] execute.c[Exec_with_parameters_resolved]444:
stmt_with_params = ';SELECT * FROM temptulemus offset 0 limit 900'
[3604-0.187] execute.c[Exec_with_parameters_resolved]449: about to begin
SC_execute
[3604-0
ndle_pgres_error]902: error message=server
closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
(137)
Andrus.
*From:* Justin
*Sent:* Friday, February 21, 2020 8:44 PM
*To:* Andrus
*Cc:* Alvaro Herrera ; A
Hi!
Alright so what does:
\d temptulemus
Did not find any relation named "temptulemus".
and/or
\d andmetp
Table "public.andmetp"
Column | Type | Collation | Nullable | Default
+---+---+--+-
andmetp| characte
On 2/21/20 12:50 PM, Andrus wrote:
Hi!
In psql what does \d tempestuous show?
What relation is andmetp to tempestuous?
I'm sorry, this was typo. Correct commands issued from application are
select drop_table('temptulemus');
create temp table temptulemus as select * from andmetp;
select * fr
Hi!
In psql what does \d tempestuous show?
What relation is andmetp to tempestuous?
I'm sorry, this was typo. Correct commands issued from application are
select drop_table('temptulemus');
create temp table temptulemus as select * from andmetp;
select * from temptulemus offset 0 limit 900;
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
Hi!
Yes publish the ODBC logs
I send psqlodbc log from windows server to you.
I added and removed Debug=1 parameter from odbc conncetion string, ran
application as administrator.
Other errors
2020-02-21 21:27:30 EET ERROR: invalid memory alloc request size
4294967293
2020-02-21 21:27:30
Yes publish the ODBC logs
seeing the Linux logs tells us the ODBC client crashing NOT the client
process. if the linux postgrsql client process crashes it typically will
cause the postgresql postmaster to panic and restart as it has to assume
it corrupt share memory.
On Fri, Feb 21, 2020 at
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 STATEMEN
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 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 L
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
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
having chased this error several times over the last 20 years, if its not
windows update, AV update, firewall config change, UAC or a driver update
it is nearly impossible to to figure out what is causing it.
One can try to run sysinternal app such as process explorer or depends to
look over the
On 2/20/20 4:50 PM, Adrian Klaver wrote:
On 2/20/20 2:48 PM, Ron wrote:
On 2/20/20 4:35 PM, Adrian Klaver wrote:
On 2/20/20 2:29 PM, Andrus wrote:
Hi!
>Then what changes were done recently, in particular ODBC-related.
Same psqlODBC driver 09.00.0101 has worked 10 years.
Previously I logged in
On 2/20/20 2:48 PM, Ron wrote:
On 2/20/20 4:35 PM, Adrian Klaver wrote:
On 2/20/20 2:29 PM, Andrus wrote:
Hi!
>Then what changes were done recently, in particular ODBC-related.
Same psqlODBC driver 09.00.0101 has worked 10 years.
Previously I logged into this server long time ago and then it w
On 2/20/20 2:42 PM, Alvaro Herrera wrote:
On 2020-Feb-20, Andrus wrote:
Upgrade to a version of Postgres that is not 5 years past EOL?
Not possible at moment because requires lot of testing not to break existing
applications.
Planned in future.
Applications are already broken, since they ca
On 2/20/20 4:35 PM, Adrian Klaver wrote:
On 2/20/20 2:29 PM, Andrus wrote:
Hi!
>Then what changes were done recently, in particular ODBC-related.
Same psqlODBC driver 09.00.0101 has worked 10 years.
Previously I logged into this server long time ago and then it worked.
Windows update history sh
On 2/20/20 2:42 PM, Alvaro Herrera wrote:
On 2020-Feb-20, Andrus wrote:
Upgrade to a version of Postgres that is not 5 years past EOL?
Not possible at moment because requires lot of testing not to break existing
applications.
Planned in future.
Applications are already broken, since they ca
On 2020-Feb-20, Andrus wrote:
> > Upgrade to a version of Postgres that is not 5 years past EOL?
>
> Not possible at moment because requires lot of testing not to break existing
> applications.
> Planned in future.
Applications are already broken, since they can't connect, right? Seems
like a g
On 2/20/20 2:29 PM, Andrus wrote:
Hi!
>Then what changes were done recently, in particular ODBC-related.
Same psqlODBC driver 09.00.0101 has worked 10 years.
Previously I logged into this server long time ago and then it worked.
Windows update history shows lot of updates all called
Security Int
On 2/20/20 1:27 PM, Andrus wrote:
Hi!
Upgrade to a version of Postgres that is not 5 years past EOL?
Not possible at moment because requires lot of testing not to break
existing applications.
Planned in future.
Alright.
Then what changes were done recently, in particular ODBC-related.
Hi!
Upgrade to a version of Postgres that is not 5 years past EOL?
Not possible at moment because requires lot of testing not to break existing
applications.
Planned in future.
Andrus.
Hi!
Given this is localhost connection, start looking at firewall or AV.
Windows firewall is turned off. It does not affect to local connections in
same computer.
I turned windows antivirus off but problem persists.
Andrus.
This error is really common and is caused by windows via UAC, SFC,
Firewarll, AV etc.. for it spontaneously to appear means system config
change happened or update occurred.
Common sources windows updates, anti-viruses changes, firewall changes.
If its not the above 4 figuring out what causin
On 2/20/20 12:35 PM, Andrus wrote:
Hi!
Every time when user tries to log on from same virtual computer where
Postgreql resides, Postgres terminates with 0xC005 exception. Log is
below.
About 65 users are accessing this server over VPN. They can use server
normally.
Logging from localho
32 matches
Mail list logo
