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
Martijn van Oosterhout writes:
> For stuff run from autovacuum, would it be reasonable for the
> automatically run version to just abort if it sees someone doing the
> same thing?
Not especially --- there's no guarantee that the other guy is going to
commit at all. And autovac is only holding on
Markus Schaber <[EMAIL PROTECTED]> writes:
> Is there any reason to allow ANALYZE run insinde a transaction at all?
I had a script to run explain over a set of queries, then run analyze, then
run explain again and check the plans for unexpected changes. It would roll
back the analyze if any prod
Hi, Andrew,
Andrew - Supernews wrote:
>> Is there any reason to allow ANALYZE run insinde a transaction at all?
>
> Absolutely. In a large transaction that radically changes the content of
> the database, it is often necessary to analyze in order to avoid getting
> extremely bad query plans for
On 2006-09-15, Markus Schaber <[EMAIL PROTECTED]> wrote:
> Is there any reason to allow ANALYZE run insinde a transaction at all?
Absolutely. In a large transaction that radically changes the content of
the database, it is often necessary to analyze in order to avoid getting
extremely bad query pl
Hi, Tom,
Tom Lane wrote:
> We could add another LockTagType just for ANALYZE, but that seems like
> rather a lot of infrastructure to support an extremely narrow corner
> case, namely two people doing database-wide ANALYZE at the same time
> inside transaction blocks. (If they do it outside a tra
On Thu, Sep 14, 2006 at 06:25:42PM -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > How would creating a new lock type avoid deadlocks when an ANALYZE is
> > accumulating the locks in random order?
>
> In itself it wouldn't. Josh Drake sketched the idea in more detail
> later:
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 rea
On Thu, 2006-09-14 at 18:25 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > How would creating a new lock type avoid deadlocks when an ANALYZE is
> > accumulating the locks in random order?
>
> In itself it wouldn't. Josh Drake sketched the idea in more detail
> later: if ther
Jeff Davis <[EMAIL PROTECTED]> writes:
> How would creating a new lock type avoid deadlocks when an ANALYZE is
> accumulating the locks in random order?
In itself it wouldn't. Josh Drake sketched the idea in more detail
later: if there is a lock type used *only* for ANALYZE, then you can do
Condi
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 in
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> 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.
> Why not an internal lock that people don't see?
We could add another LockTagType just for
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-transact
andy <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> andy <[EMAIL PROTECTED]> writes:
>>> So I'm ok, but I tried it again, by dropping the database and re-running
>>> both scripts and got the same error again. So thought I'd offer a test
>>> case if there was interest.
>>
>> Absolutely. I've
14 matches
Mail list logo
