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?

        Jeff Davis

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to