Richard Huxton <dev@archonet.com> writes: > Hmm - odd that you're not getting any connection details. Not really; the autovacuum process doesn't have any connection, so those log_line_prefix fields will be left empty. The weird thing about this is why the large maintenance_work_mem works for a regular session and not for autovacuum. There really shouldn't be much difference in the maximum workable setting for the two cases, AFAICS. Your later suggestion to check out the postgres user's ulimit -a settings seems like the appropriate next step, but I'm not seeing how ulimit would affect only some of the postmaster's children. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

I wrote: > ... The weird thing about this > is why the large maintenance_work_mem works for a regular session and > not for autovacuum. There really shouldn't be much difference in the > maximum workable setting for the two cases, AFAICS. After re-reading the thread I realized that the OP is comparing manual VACUUM FULL to automatic plain VACUUM, so the mystery is solved. Plain VACUUM tries to grab a maintenance_work_mem-sized array of tuple IDs immediately at command startup. VACUUM FULL doesn't work like that. Given the 200M ulimit -v, and the shared_buffers setting of 20000 (about 160M), the behavior is all explained if we assume that shared memory counts against -v. Which I think it does. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend