Vivek Khera wrote:

"MTO" == Matthew T O'Connor <[EMAIL PROTECTED]> 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




---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Reply via email to