Tom Lane wrote:
Jeff Davis <[EMAIL PROTECTED]> writes:
Couldn't you just sort by the table names, and ANALYZE the tables in
that order? Would that effectively prevent the deadlocks?
That'd work too, I think (I suggested the variant of ordering by OID,
which is simpler and more reliable). Not sure if it's really worth the
trouble though --- how many people do you think are doing concurrent
whole-database ANALYZEs inside transaction blocks?
As-is the code will do the analyzes in pg_class physical row order,
which is almost good enough --- only if someone did a schema change that
forced a pg_class row update between the starts of the two ANALYZE runs
would it possibly fail. So the use-case for a fix is really kinda narrow.
regards, tom lane
Honestly, its not that big a problem, and if there were some doc's,
faq's, etc (and people on the newsgroups) I dont think you should even
worry about it.
It makes sense to me, and if Tom had come back and said, yeah, here is
why, cuz you run autovacuum and at then end of the script you did a
vacuum... they are conflicting... dont do that. I'd be cool with that.
As soon as its common knowledge I think it could be avoided.
Really, isn't it just bulk loads anyway where a person might do this?
-Andy
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
