On Thu, 2006-09-14 at 11:20 -0400, Tom Lane wrote:
> andy <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> andy <[EMAIL PROTECTED]> writes:
> This behavior dates from a time when there was no good alternative.
> One possible fix today would be to make ANALYZE take
> ShareUpdateExclusive lock instead, thus ensuring there is only one
> ANALYZE at a time on a table. However I'm a bit concerned by the
> possibility that ANALYZE-inside-a-transaction could accumulate a
> whole bunch of such locks in a random order, leading at least to
> a risk of deadlocks against other ANALYZEs. (We have to hold the
> lock till commit, else we aren't fixing the problem.) Do we need a
> specialized lock type just for ANALYZE? Would sorting the target
> list of rel OIDs be enough? Perhaps it's not worth worrying about?
>
How would creating a new lock type avoid deadlocks when an ANALYZE is
accumulating the locks in random order?
Regards,
Jeff Davis
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
