On Sunday 15 February 2004 02:54 pm, Mark Lubratt wrote:
> I've finally decided to upgrade my postgresql installation. I'm
> currently running 7.3.2 on RedHat 9.0.
> Here's my dilemma: Since RedHat is no longer supporting their "RedHat"
> distributions, I can't really get a RPM for the upgrade.
Mark Lubratt <[EMAIL PROTECTED]> writes:
> Here's my dilemma: Since RedHat is no longer supporting their "RedHat"
> distributions, I can't really get a RPM for the upgrade.
Sure you can ... just not from Red Hat :-(
AFAIK the RHEL3 RPMs will work fine on RH9. If you are feeling
paranoid, grab
Do you use PuTTy as the ssh client? If yes then here you are ,it
is the connection problem .i have it all the time and did not found
what to do with.Actually that is not only putty problem ,but for
example linux ssh client at least does not just freeze - it says
something like 'connection timeout'
Hi Evgeny,
yes I am PUTTY. I knew it wasn't a postgres problem, but thought there might be some
server variable controlling timeout. I didn't know that other SSH clients didn't have
the same thing happen. Since I am logging to my machine remotely, I can't use the
linux ssh client, but I'll s
I looked at putty's help documentation and found a keep-alive setting that will send
empty packets every so often to keep the session active. It's pretty much the same
thing that happens when FTPing to a remote server, and this is of course the same
recourse used to keep FTPs from timing out as
I've finally decided to upgrade my postgresql installation. I'm
currently running 7.3.2 on RedHat 9.0.
Here's my dilemma: Since RedHat is no longer supporting their "RedHat"
distributions, I can't really get a RPM for the upgrade. I'm concerned
about orphaning files if I do a straight compil
"Marc Mitchell" <[EMAIL PROTECTED]> writes:
> So long as the idled transaction isn't holding any locks on any data
> resources, I don't know if this condition is a bad thing. It would be
> nice to be able to differentiate between a transaction that has been
> "declared" but has yet to really begin
We see the exact same condition when setting "setAutoCommit(FALSE)".
However, we expected that situation based on what we understand as the
way such a setting manifests itself within the
Multi-Statement-Transaction handling of Postgres. Furthermore, we saw
this exact same behavior under at least
"Jeremy Smith" <[EMAIL PROTECTED]> writes:
> I know this isn't strictly a postgresql question, but I'm sure it applies to
> others out there using psql. If I am working in psql from SSH and switch to
> another window, it seems that there is a very short window of time before
> the window freezes a
Just a very quick thought, have You issued a:
connection.commit();
Regards,
Søren,
Subject:[ADMIN] idle in transaction
From: Warren Little <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date sent: Sun, 15 Feb 2004 09:23:32 -0700
> We
We recently upgraded postgres from 7.3 to 7.4, along with the JDBC jar,
and noticed all the backend processes/connections are left in the "idle
in transaction" state where before they where left in the "idle" state.
Has something changed in the 7.4 jdbc driver vs 7.3 which might be
causing this?
No
pgsql-adminHi:
I have a serious problem installing PostgreSQL 7.4.1 on Windows.
I have an up-to-date cygwin 1.5.7 installation under Windows2000 Server sp3,
installed the cygipc 2.0 package as instructed,
but I fail to initialize the database.
The output is:
$ ls -al /usr/local/pgsql/
total 0
dr
12 matches
Mail list logo
