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
