Re: [ADMIN] Vacuum error on database postgres

From: andy <andy(at)squeakycode(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [ADMIN] Vacuum error on database postgres
Date: 2006-09-15 01:45:01
Message-ID: 450A059D.4090400@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> 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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message david.lao 2006-09-15 01:49:42 Re: real and effective user ids must match
Previous Message Michael Fuhr 2006-09-15 01:41:46 Re: real and effective user ids must match

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2006-09-15 03:01:26 Re: Mid cycle release?
Previous Message Golden Liu 2006-09-15 01:16:33 Unique index: update error