From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Missing dependency tracking for TableFunc nodes
Date: Thu, 14 Nov 2019 23:22:32 +0100
Message-ID: <20191114222232.o76u6jdvf53ozjjk@development> (raw)
In-Reply-To: <14155.1573767414@sss.pgh.pa.us>
References: <18427.1573508501@sss.pgh.pa.us>
<997cbcae-7739-f871-84a0-1192380abb54@gmail.com>
<15228.1573695479@sss.pgh.pa.us>
<20191114213124.i6xwx24y26iklzds@development>
<14155.1573767414@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, tgl@sss.pgh.pa.us, hornschnorter@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Missing dependency tracking for TableFunc nodes
In-Reply-To: <20191114222232.o76u6jdvf53ozjjk@development>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox