Tom Lane wrote: > Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> writes: > > An alternative solution would be to lower the vacuum delay settings before > > starting the truncating phase, but this doesn't work very well in autovacuum > > due to the autobalancing code (which can cause other processes to change our > > cost delay settings). This case could be considered in the balancing code, but > > it is simpler this way. > > I don't think autovacuum has a problem --- if someone requests a > conflicting lock, autovac will get kicked off, no? The OP's problem > comes from doing a manual vacuum. Perhaps "don't do that" is a good > enough answer. Hah, that was part of the commit message, which predates autovacuum getting kicked out in case of conflicting locks IIRC. I think the process being described is unusual enough that a manual vacuum at just the right time is warranted ... -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general