On Thu, Nov 14, 2019 at 05:35:06PM -0500, Tom Lane wrote:
Tomas Vondra 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
On Thu, Nov 14, 2019 at 07:27:29PM -0300, Alvaro Herrera wrote:
On 2019-Nov-14, Tomas Vondra wrote:
Isn't that solved by RemoveObjects() doing this?
/* Get an ObjectAddress for the object. */
address = get_object_address(stmt->removeType,
object,
Tomas Vondra 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,
>> o
On 2019-Nov-14, Tomas Vondra wrote:
> Isn't that solved by RemoveObjects() doing this?
>
>/* Get an ObjectAddress for the object. */
>address = get_object_address(stmt->removeType,
> object,
> &relation,
>
On Thu, Nov 14, 2019 at 04:36:54PM -0500, Tom Lane wrote:
Tomas Vondra 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
Tomas Vondra 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
>> lock
On Wed, Nov 13, 2019 at 08:37:59PM -0500, Tom Lane wrote:
Mark Dilger 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 n
On 11/13/19 4:46 PM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 03:00:03PM -0800, Mark Dilger wrote:
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 collatio
Mark Dilger 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
On Wed, Nov 13, 2019 at 03:00:03PM -0800, Mark Dilger wrote:
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.
This can be
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.
This can be demonstrated to be a problem by the attached script,
which w
On 2019-11-12 15:32:14 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-11-12 10:19:30 -0500, Tom Lane wrote:
> >> I could imagine annotations that say "this field contains a function OID"
> >> or "this list contains collation OIDs" and then the find_expr_references
> >> logic could be d
Andres Freund writes:
> On 2019-11-12 10:19:30 -0500, Tom Lane wrote:
>> I could imagine annotations that say "this field contains a function OID"
>> or "this list contains collation OIDs" and then the find_expr_references
>> logic could be derived from that.
> I want to attach some annotations t
Hi,
On 2019-11-12 10:19:30 -0500, Tom Lane wrote:
> I think that the long-term answer, if Andres gets somewhere with his
> project to autogenerate code like this, is that we'd rely on annotating
> the struct declarations to tell us what to do. In the case at hand,
> I could imagine annotations th
Mark Dilger writes:
> I played with this a bit, making the change I proposed, and got lots of
> warnings from the compiler. I don't know how many of these would need
> to be suppressed by adding a no-op for them at the end of the switch vs.
> how many need to be handled, but the attached patch
On 11/11/19 2:33 PM, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
Would it be a good idea to move find_expr_references_walker to
nodeFuncs.c, in hopes of making it more visible to people adding
new node types?
I'm not sure that would be enough. The logic of that function is not
On 11/11/19 1:41 PM, Tom Lane wrote:
Would it be a good idea to move find_expr_references_walker to
nodeFuncs.c, in hopes of making it more visible to people adding
new node types?
I'm not sure that would be enough. The logic of that function is not
immediately obvious, and where to add a
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.
This can be demonstrated to be a problem by the attached script,
which will end up with a "cache lookup failed for
18 matches
Mail list logo
