Thanks Tom...

The Linux box was completely idle (as you already guessed). There were multiple locks on the table(s) in question. And to answer your question, we are heavily using domain types. I suspect (to refresh your memory) that the problem reported earlier was from Kevin Grittner. Do you know if there are any plans to have better utilization of domain types in Postgres?

The steps I took to resolve the problem was to completely kill all processes, restarted the Postgres service, and then ran "vacuum full analyze" upon a successful restart. That went through without a hitch.

Thanks again... let me know if you can think of anything that could/would prevent this problem in the future (outside of eliminating domain types).

Jeff Kirby

>>> Tom Lane <tgl@sss.pgh.pa.us> 10/02/05 8:53 PM >>>
"Jeff Kirby" <Jeff.Kirby@wicourts.gov> writes:
> the Linux box however is still chugging away this morning... and
> appears to be stuck on vacuuming "pg_constraint_contypid_index". How
> do I know... well I don't really... I'm inferring based on the order
> of the log output on the Windows box.

Looking in pg_locks would give you a more reliable indicator of what the
VACUUM is currently working on.

Is the Linux box otherwise idle? There was another report recently of a
vacuum hung up for a long time on pg_constraint_contypid_index, but it
seemed to be due to extremely heavy usage of domain types ...

regards, tom lane


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