Hello,
Thanks for the help...It appears that a transaction is indeed being
opened and remains idle. I am able to identify the postgreSQL backend
process that is associated with the transaction, however, I need to
further localize the issue. We have around 22 (postgres) backend
processes associated with various application processes. I would like
to identify our application process.
I have tried using netstat -ap and looking through the logs..but, to no
avail. (Both the database and the server processes are running on the
same server...connected via unix sockets I believe, perhaps this is
making the association difficult to determine).
Any ideas of how to identify the application process that is the
postgres process (whose id I know). Perhaps I need to turn on a
different log flag?
Thanks
Ike
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, August 21, 2006 2:06 PM
To: Eamonn Kent
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Vacuum not identifying rows for removal..
"Eamonn Kent" <ekent@xsigo.com> writes:
> I am using PostgreSQL 8.1.4 for an embedded application. For some
> reason, vacuum is not able to identify rows that are candidates for
> removal (i.e., mark space as available).
> ...
> We run auto vacuum and I can see from the logs that it is running
quite
> frequently. When I run vacuum full from the psql, I can see that space
> is not being recovered. I have run vacuum full with the verbose flag
> set, I can see that messages that indicate the existence of "dead row
> versions that cannot be removed yet.
This means you've got an open transaction somewhere that could
potentially still be able to see those rows. Look around for
applications sitting "idle in transaction".
regards, tom lane
