Re: autovacuum daemon stops doing work after about an hour

Vivek Khera wrote:

>>>>>>"MTO" == Matthew T O'Connor <matthew@zeut.net> writes:
>
>
>>>Then it just sits there.  I started it at 11:35am, and it is now
>>>3:30pm.
>
>
> MTO> Weird.... Alphabetically speaking, is vkmlm."public"."user_list" be the
> MTO> last table in the last schema in the last database?  You are running
>
> conveniently, yes it is...
>
> MTO> with -d4, so you would get a message about going to sleep shortly after
> MTO> dealing with the last table, but you didn't get the sleep message, so I
> MTO> don't think the problem is that pg_autovacuum is sleeping for an
> MTO> inordinate amount time.
>
> The only sleep logged was
>
> [2003-12-03 04:47:13 PM] 1 All DBs checked in: 84996853 usec, will sleep for 469 secs.

What I seen is:


# tail -f auto.log
[2003-12-04 07:10:18 PM] reltuples: 72;  relpages: 1
[2003-12-04 07:10:18 PM] curr_analyze_count:  72; cur_delete_count:   0
[2003-12-04 07:10:18 PM] ins_at_last_analyze: 72; del_at_last_vacuum: 0
[2003-12-04 07:10:18 PM] insert_threshold:    572; delete_threshold    536
[2003-12-04 07:10:18 PM] table name:     empdb."public"."contracts"
[2003-12-04 07:10:18 PM] relfilenode: 17784;   relisshared: 0
[2003-12-04 07:10:18 PM] reltuples: 347;  relpages: 5
[2003-12-04 07:10:18 PM] curr_analyze_count:  347; cur_delete_count:   0
[2003-12-04 07:10:18 PM] ins_at_last_analyze: 347; del_at_last_vacuum: 0
[2003-12-04 07:10:18 PM] insert_threshold:    847; delete_threshold    673


[ 5 minutes of delay ]  <----- LOOK THIS


[2003-12-04 07:10:18 PM] 503 All DBs checked in: 179396 usec, will sleep
for 300 secs.
[2003-12-04 07:15:19 PM] 504 All DBs checked in: 98814 usec, will sleep
for 300 secs.

I think is a good Idea put a fflush after:

fprintf(LOGOUTPUT, "[%s] %s\n", timebuffer, logentry);


Regards
Gaetano Mendola