The problem is on pg_listener table. I found the same problem on my test
3 node set up.

I printed the table contents, then did a vacuum full. I then waited 5
minutes, print the table contents and do a vacuum full again.

The table details have not changed, all the same slony pids. We have no
listens on public tables on this particular database so its easy to see
what is going on. To the very best of my knowledge there have been no
inserts and deletes to this table since the last print, 5 minutes ago.

I paste the vacuum results below. I've never read the vacuum verbose
reports before so any guidance on what to look for would be appreciated.
The lines that appear to be of interest are

INFO:  "pg_listener": found 1036 removable, 12 nonremovable row versions
in 16 pages
INFO:  "pg_listener": moved 5 row versions, truncated 16 to 1 pages

I can wait 5 minutes and repeat and another 16-18 pages of data will
again be truncated into 1 page. Where is al this extra data coming from.
I don't want to jump slony but it seems much worse on the 11 node
system, which is where the problem first came to light.

Vicki


sss=# vacuum full verbose pg_listener;
INFO:  vacuuming "pg_catalog.pg_listener"
INFO:  "pg_listener": found 1036 removable, 12 nonremovable row versions
in 16 pages
DETAIL:  0 dead row versions cannot be removed yet.
Nonremovable row versions range from 96 to 96 bytes long.
There were 0 unused item pointers.
Total free space (including removable row versions) is 125408 bytes.
10 pages are or will become empty, including 0 at the end of the table.
16 pages containing 125408 free bytes are potential move destinations.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "pg_listener": moved 5 row versions, truncated 16 to 1 pages
DETAIL:  CPU 0.00s/0.00u sec elapsed 0.07 sec.
VACUUM




-----Original Message-----
From: Christopher Browne [mailto:cbbrowne at ca.afilias.info] 
Sent: 22 March 2007 16:05
To: Victoria Parsons
Cc: slony
Subject: Re: [Slony1-general] Vacuum full required?

"Victoria Parsons" <victoria.parsons at streamshield.com> writes:
> Has anyone else found that they need a vacuum full to keep their
> replication, and/or general postgres use up to speed? Have I
> mis-understood the use of vacuum full, and does it do more than just
> recover disk space? Next time it goes wrong I will do vacuum full on
> a table at a time to see if I can narrow down the culprit.

We *never* run a VACUUM FULL on a whole database; just occasionally on
some very carefully selected table.

Definitely you should narrow it down, and run VACUUM FULL ANALYZE on
each table to see where you get a huge reclaiming of space.  By all
means, report back on your findings, that may help us help you, and
help others, as well...
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)


This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy 
by an authorized signatory.