Re: Missing dependency tracking for TableFunc nodes
От | Tomas Vondra |
---|---|
Тема | Re: Missing dependency tracking for TableFunc nodes |
Дата | |
Msg-id | 20191114222232.o76u6jdvf53ozjjk@development обсуждение исходный текст |
Ответ на | Re: Missing dependency tracking for TableFunc nodes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Missing dependency tracking for TableFunc nodes
Re: Missing dependency tracking for TableFunc nodes |
Список | pgsql-hackers |
On Thu, Nov 14, 2019 at 04:36:54PM -0500, Tom Lane wrote: >Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: >> On Wed, Nov 13, 2019 at 08:37:59PM -0500, Tom Lane wrote: >>> I concur with Tomas' suspicion that this must be a race condition >>> during DROP STATISTICS. If we're going to allow people to do that >>> separately from dropping the table(s), there has to be some kind of >>> locking around it, and it sounds like there's not :-( > >> I think the right thing to do is simply acquire AE lock on the relation >> in RemoveStatisticsById, per the attached patch. It's possible we'll >> need to do something more complicated once join stats are added, but >> for now this should be enough (and backpatchable). > >Hm. No, it's not enough, unless you add more logic to deal with the >possibility that the stats object is gone by the time you have the >table lock. Consider e.g. two concurrent DROP STATISTICS commands, >or a statistics drop that's cascading from something like a drop >of a relevant function and so has no earlier table lock. > Isn't that solved by RemoveObjects() doing this? /* Get an ObjectAddress for the object. */ address = get_object_address(stmt->removeType, object, &relation, AccessExclusiveLock, stmt->missing_ok); I've actually done some debugging before sending the patch, and I think this prevent the issue you describe. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: