Re: Berserk Autovacuum (let's save next Mandrill) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Berserk Autovacuum (let's save next Mandrill)
Date
Msg-id 490.1585687710@sss.pgh.pa.us
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Berserk Autovacuum (let's save next Mandrill)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> I had a go at reproducing this. I wasn't able to produce the reported
> failure, but I can reliably produce an Assert failure that may be
> related by doing a VACUUM FULL simultaneously with an ANALYZE that is
> generating extended stats, which produces:
> ...
> It looks to me as though the problem is that statext_store() needs to
> take its lock on pg_statistic_ext_data *before* searching for the
> stats tuple to update.

Hmm, yeah, that seems like clearly a bad idea.

> It's late here, so I haven't worked up a patch yet, but it looks
> pretty straightforward.

I can take care of it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rethinking opclass member checks and dependency strength
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots