Re: [ADMIN] Vacuum error on database postgres - Mailing list pgsql-hackers

From andy
Subject Re: [ADMIN] Vacuum error on database postgres
Date
Msg-id 450A059D.4090400@squeakycode.net
Whole thread Raw
In response to Re: [ADMIN] Vacuum error on database postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.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
couldbe avoided.
 

Really, isn't it just bulk loads anyway where a person might do this?

-Andy


pgsql-hackers by date:

Previous
From: Tom Dunstan
Date:
Subject: Re: Mid cycle release?
Next
From: Pascal Meunier
Date:
Subject: minor feature request: Secure defaults during function creation