From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <hornschnorter(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Missing dependency tracking for TableFunc nodes |
Date: | 2019-11-14 23:28:57 |
Message-ID: | 20191114232857.fhnbuxs4bgcy7llm@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 14, 2019 at 05:35:06PM -0500, Tom Lane wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On Thu, Nov 14, 2019 at 04:36:54PM -0500, Tom Lane wrote:
>>> 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);
>
>Ah, I see, we already have AEL on the stats object itself. So that
>eliminates my concern about a race between two RemoveStatisticsById
>calls, but what we have instead is fear of deadlock. A DROP STATISTICS
>command will acquire AEL on the stats object but then AEL on the table,
>the opposite of what will happen during DROP TABLE, so concurrent
>executions of those will deadlock. That might be better than the
>failures Mark is seeing now, but not by much.
>
Hmmm, yeah :-(
>A correct fix I think is that the planner ought to acquire AccessShareLock
>on a stats object it's trying to use (and then recheck whether the object
>is still there). That seems rather expensive, but there may be no other
>way.
Yes, so something like for indexes, although we don't need the recheck
in that case. I think the attached patch does that (but it's 1AM here).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
stats-locking-v2.patch | text/plain | 1.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2019-11-14 23:32:55 | Re: format of pg_upgrade loadable_libraries warning |
Previous Message | Tomas Vondra | 2019-11-14 23:06:46 | Re: Missing dependency tracking for TableFunc nodes |