Hi, Matteo,
Matteo Sgalaberni wrote:
A my collegue JDBC application that stay in idle intransaction 24h/24h
Just a little note: For most applications, this can be fixed updating
the JDBC driver. Old versions had the behaviour of auto-opening a new
backend transaction on commit/rollback,
Tom Lane [EMAIL PROTECTED] writes:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Good to know this...but why this behaviour? it'is lovely...:)
Open transactions are tracked across the whole cluster. This is
necessary when vacuuming shared catalogs. In principle we could
track per-database
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Good to know this...but why this behaviour? it'is lovely...:)
Open transactions are tracked across the whole cluster. This is
necessary when vacuuming shared catalogs. In principle
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Good to know this...but why this behaviour? it'is lovely...:)
Open transactions are tracked across the whole cluster. This is
Gregory Stark [EMAIL PROTECTED] writes:
I must be misunderstanding Tom's comment then.
What I'm referring to is lazy_vacuum_rel() calls vacuum_set_xid_limits with
the relisshared flag of the relation. vacuum_set_xid_limits passes that to
GetOldestXmin as the allDbs parameter. GetOldestXmin
On Fri, Sep 01, 2006 at 01:35:20PM -0400, Tom Lane wrote:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Ok. I stopped all clients. No connections to this database.
When you say this database, do you mean the whole postmaster cluster,
or just the one database? Open transactions in other
Matteo,
On 2-Sep-06, at 4:37 AM, Matteo Sgalaberni wrote:
On Fri, Sep 01, 2006 at 01:35:20PM -0400, Tom Lane wrote:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Ok. I stopped all clients. No connections to this database.
When you say this database, do you mean the whole postmaster
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Good to know this...but why this behaviour? it'is lovely...:)
Open transactions are tracked across the whole cluster. This is
necessary when vacuuming shared catalogs. In principle we could
track per-database xmin values as well, but the distributed
Hi, probably this is a very frequenfly question... I read archivies of
this list but I didn't found a finally solution for this aspect. I'll
explain my situation.
PSQL version 8.1.3
configuration of fsm,etcc default
autovacuum and statistics activated
22 daemons that have a persistent connection
Matteo Sgalaberni [EMAIL PROTECTED] writes:
22 daemons that have a persistent connection to this database(all
connection are in idle(no transaction opened).
You may think that, but you are wrong.
INFO: cliente: found 0 removable, 29931 nonremovable row versions in 559
pages
DETAIL: 29398
Are there open transactions on the table in question? We had the same
issue. A 100K row table was so bloated that the system thought there was
1M rows. We had many IDLE transaction that we noticed in TOP, but since
we could not track down which process or user was holding the table we had
to
Hi, Tom and Matteo,
Tom Lane wrote:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
22 daemons that have a persistent connection to this database(all
connection are in idle(no transaction opened).
You may think that, but you are wrong.
INFO: cliente: found 0 removable, 29931 nonremovable
On Fri, Sep 01, 2006 at 10:43:30AM -0400, Tom Lane wrote:
Matteo Sgalaberni [EMAIL PROTECTED] writes:
22 daemons that have a persistent connection to this database(all
connection are in idle(no transaction opened).
You may think that, but you are wrong.
Ok. I stopped all clients. No
Matteo Sgalaberni [EMAIL PROTECTED] writes:
Ok. I stopped all clients. No connections to this database.
When you say this database, do you mean the whole postmaster cluster,
or just the one database? Open transactions in other databases of the
same cluster can be a problem.
14 matches
Mail list logo
