The observations made already wondering if there are any long-running
transactions lurking around fit with what I'd wonder, too.  If there's
something like a pg_dump or some long running report that holds a
transaction open for a couple hours, that would certainly explain the
phenomenon, and it's unfortunate that this leads to big growth of
sl_log_*

I wonder if this is a case that would get helped by BRIN indexes.

Note that this is an experimental proposal I have lurking about...

https://github.com/cbbrowne/slony1-engine/commit/7a02c20cde8c8f3a54914ca6889d392074d51503

The index requests are (with @NAMESPACE@ as a needful schema substitution):

create index sl_log_1_brin_txid on @NAMESPACE at .sl_log_1 using BRIN (log_txid);
create index sl_log_2_brin_txid on @NAMESPACE at .sl_log_2 using BRIN (log_txid);
create index sl_log_1_brin_action on @NAMESPACE at .sl_log_1 using BRIN
(log_actionseq);
create index sl_log_2_brin_action on @NAMESPACE at .sl_log_2 using BRIN
(log_actionseq);

It mightn't help, and certainly won't, if the backends aren't on
versions supporting BRIN (only in PG 9.5+), but on the other hand, it
might.  (And if it's a big win, that would be REALLY nice to know!
I'll bet the folks that worked on BRIN indexes would also be happy to
hear it!)