Re: BUG #17152: ERROR: AddressSanitizer: SEGV on iso-8859-1 address - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17152: ERROR: AddressSanitizer: SEGV on iso-8859-1 address
Date
Msg-id 1636533.1629325925@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17152: ERROR: AddressSanitizer: SEGV on iso-8859-1 address  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
I wrote:
> I'm not too concerned about this cosmetic difference, but I wonder
> if there are any cases where check_agglevels_and_constraints will
> throw an error when it shouldn't.  Right offhand I can't see any,
> but I may just lack imagination today.

After further study I've more or less convinced myself that that
isn't an issue.  We may consider these cases:

1. We are parsing an aggregate call that's inside a FILTER clause
of the current query level.

1a. If we identify the aggregate as being of the current query level,
we will look at the current pstate, see p_expr_kind ==
EXPR_KIND_FILTER, and throw an error.  That is correct, because the
existence of this aggregate would constrain the surrounding aggregate
to also have the current query level as semantic level.

1b. If we identify the aggregate as being of some outer query level,
we will look at that outer pstate and probably not see
EXPR_KIND_FILTER (see #2 for the case where we do see that).  In
this case check_agglevels_and_constraints will not throw an error,
which is fine because we can't yet know the semantic levels of
surrounding aggregate(s).  It's left to check_agg_arguments, when
it checks the surrounding aggregate, to throw an error if needed.

2. We are parsing an aggregate call that's inside a FILTER clause
of some outer query level (i.e., the current aggregate is inside
a sub-SELECT inside FILTER).

2a. If we identify the aggregate as being of that same outer
query level, we will see EXPR_KIND_FILTER and throw error.
As in #1a, the error is correct since we'd ultimately assign
that outer aggregate to its own syntactic level.  (It clearly
can't have a semantic level lower than its syntactic level,
and again the existence of this aggregate within its arguments
prevents it from being assigned to any higher level.)

2b. If we identify the aggregate as being of some other query level
where there is not an open FILTER clause, we will not throw error.
As in #1b, it's up to check_agg_arguments to do so if needed.

So I think the patch I presented is sufficient.  I added some
test cases and pushed it.

Thanks for the report!

            regards, tom lane



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: PGSQL bug - "Column ??? is an identity column defined as GENERATED ALWAYS.",
Next
From: Tom Lane
Date:
Subject: Re: BUG #17151: A SEGV in optimizer