From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: Missing dependency tracking for TableFunc nodes
Date: Wed, 13 Nov 2019 20:37:59 -0500
Message-ID: <15228.1573695479@sss.pgh.pa.us> (raw)
In-Reply-To: <997cbcae-7739-f871-84a0-1192380abb54@gmail.com>
References: <18427.1573508501@sss.pgh.pa.us>
<997cbcae-7739-f871-84a0-1192380abb54@gmail.com>
Mark Dilger <hornschnorter@gmail.com> writes:
> On 11/11/19 1:41 PM, Tom Lane wrote:
>> I happened to notice that find_expr_references_walker has not
>> been taught anything about TableFunc nodes, which means it will
>> miss the type and collation OIDs embedded in such a node.
> I can consistently generate errors like the following in master:
> ERROR: cache lookup failed for statistics object 31041
This is surely a completely different issue --- there are not,
one hopes, any extended-stats OIDs embedded in views or other
query trees.
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 :-(
regards, tom lane
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: tgl@sss.pgh.pa.us, hornschnorter@gmail.com, tomas.vondra@2ndquadrant.com
Subject: Re: Missing dependency tracking for TableFunc nodes
In-Reply-To: <15228.1573695479@sss.pgh.pa.us>
* 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