On Wed, 16 Jan 2013 23:42:23 +0100
"T. E. Lawrence" <[email protected]> wrote:

> 
> On 15.01.2013, at 17:32, Jeff Janes <[email protected]> wrote:
> > T.E., Fortunately in point releases from August 2012 (9.0.9, 9.1.5,
> > etc.), the default server log settings will log both the cancel and
> > the command triggering the cancel.  So if you are running an up to
> > date server, you can just look in the logs to see what is happening.
> > 
> > Cheers,
> > 
> > Jeff
> 
> That's interesting, I'll check it. Thank you.

And now the million dollars question, do you have any transaction in 'IDLE IN 
TRANSACTION' state? 

If yes, there's one possible problem. For example, we used (note the past) a 
message queue middleware which uses a postgres db for message passing, but it 
keeps the transaction in 'IDLE IN TRANSACTION' state, so if i do a select * 
from message_tbl i get 1-5 rows, but the tbl used (note again the past) several 
Gb of hd space because autovacuum couldn't clean. Of course once discovered the 
problem the middleware was changed by another (home-built) one which don't 
keeps the IDLE IN TRANSACTION state.

> T.
> 
> 
> -- 
> Sent via pgsql-general mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


---   ---
Eduardo Morras <[email protected]>


-- 
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to