Re: BUG #17152: ERROR: AddressSanitizer: SEGV on iso-8859-1 address

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17152: ERROR: AddressSanitizer: SEGV on iso-8859-1 address
Дата
Msg-id 1636533.1629325925@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17152: ERROR: AddressSanitizer: SEGV on iso-8859-1 address  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PGSQL bug - "Column ??? is an identity column defined as GENERATED ALWAYS.",
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17151: A SEGV in optimizer