On Wed, 16 Jan 2013 23:42:23 +0100 "T. E. Lawrence" <t.e.lawrence@xxxxxxxxxx> wrote: > > On 15.01.2013, at 17:32, Jeff Janes <jeff.janes@xxxxxxxxx> 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 (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general --- --- Eduardo Morras <emorrasg@xxxxxxxx> -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
