public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 2/3] Allow composite types in bootstrap
6+ messages / 5 participants
[nested] [flat]
* [PATCH 2/3] Allow composite types in bootstrap
@ 2020-11-17 15:28 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw)
---
src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 18eb62ca47..e4fc75ab84 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -916,6 +916,7 @@ gettype(char *type)
{
if (Typ != NIL)
{
+ static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types */
ListCell *lc;
foreach (lc, Typ)
@@ -927,6 +928,33 @@ gettype(char *type)
return app->am_oid;
}
}
+
+ /*
+ * The type wasn't known; check again to handle composite
+ * types, added since first populating the array.
+ */
+
+ /*
+ * Once all the types are populated and we handled composite
+ * types, shouldn't need to do that again.
+ */
+ Assert(!did_reread);
+ did_reread = true;
+
+ list_free_deep(Typ);
+ Typ = NULL;
+ populate_typ_array();
+
+ /* Need to avoid infinite recursion... */
+ foreach (lc, Typ)
+ {
+ struct typmap *app = lfirst(lc);
+ if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0)
+ {
+ Ap = app;
+ return app->am_oid;
+ }
+ }
}
else
{
--
2.26.2
--------------1F4A19FEB5D90C72707AFA7B
Content-Type: text/x-patch; charset=UTF-8;
name="0003-Extended-statistics-on-expressions-20210122.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0003-Extended-statistics-on-expressions-20210122.patch"
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Check for TupleTableSlot nullness before dereferencing
@ 2024-10-09 15:23 Alexander Kuznetsov <[email protected]>
2024-12-13 08:54 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Kuznetsov @ 2024-10-09 15:23 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>; [email protected]; [email protected]
03.10.2024 12:48, Daniel Gustafsson wrote:
> From a quick reading we can only reach there after evaluating an expression, so
> can it really be null though? This code hasn't changed all that much since
> 2009, if there was a reachable segfault on a null pointer deref I have a
> feeling we'd heard about it by now so some extra care seems warranted to ensure
> it's not a static analyzer false positive.
Thanks for your response!
It seems to me that dereferencing is possible under the following scenario:
1. slot2 is NULL at line 968,
2. The while loop at line 971 executes once, filling slot1 (slot2 still remains NULL),
3. No changes occur to slot2 thereafter, up to line 1003,
4. At line 1003, slot2 is swapped with slot1 (assuming numDistinctCols > 0),
5. At line 1016, slot1 is dereferenced with conent of slot2 (NULL).
This entire reasoning is based on the assumption that slot2 can theoretically be NULL, as there is such a check at line 968.
Is it possible that no errors have occurred because this condition has always been satisfied and is, perhaps, redundant, or maybe I'm misunderstanding something?
--
Best regards,
Alexander Kuznetsov
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Check for TupleTableSlot nullness before dereferencing
2024-10-09 15:23 Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
@ 2024-12-13 08:54 ` Alexander Kuznetsov <[email protected]>
2025-04-22 07:45 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Nikolay Shaplov <[email protected]>
2025-07-21 22:20 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Jacob Champion <[email protected]>
0 siblings, 2 replies; 6+ messages in thread
From: Alexander Kuznetsov @ 2024-12-13 08:54 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>; [email protected]; [email protected]
Hello,
ping. What do you think about reasoning below? Maybe we should consider
proposing different patch for removing redundant check there?
09.10.2024 18:23, Alexander Kuznetsov wrote:
> 03.10.2024 12:48, Daniel Gustafsson wrote:
>> From a quick reading we can only reach there after evaluating an expression, so
>> can it really be null though? This code hasn't changed all that much since
>> 2009, if there was a reachable segfault on a null pointer deref I have a
>> feeling we'd heard about it by now so some extra care seems warranted to ensure
>> it's not a static analyzer false positive.
> Thanks for your response!
> It seems to me that dereferencing is possible under the following scenario:
> [...]
> This entire reasoning is based on the assumption that slot2 can theoretically be NULL, as there is such a check at line 968.
> Is it possible that no errors have occurred because this condition has always been satisfied and is, perhaps, redundant, or maybe I'm misunderstanding something?
--
Best regards,
Alexander Kuznetsov
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Check for TupleTableSlot nullness before dereferencing
2024-10-09 15:23 Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
2024-12-13 08:54 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
@ 2025-04-22 07:45 ` Nikolay Shaplov <[email protected]>
1 sibling, 0 replies; 6+ messages in thread
From: Nikolay Shaplov @ 2025-04-22 07:45 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; [email protected]; +Cc: PostgreSQL Developers <[email protected]>; [email protected]; [email protected]; [email protected]
В письме от пятница, 13 декабря 2024 г. 11:54:35 MSK пользователь Alexander
Kuznetsov написал:
> Hello,
>
> ping. What do you think about reasoning below? Maybe we should consider
> proposing different patch for removing redundant check there?
Hi!
Please, pay attention that commitfest entry for this patch
https://commitfest.postgresql.org/patch/5662/
reports problems with windows build.
There is a small chance that this is flase alarm, sometimes checkers fails for
their own reason. But most probably this is persistent error, and if it is,
this problem should be researched first of all, and fixed. Only after that there
there can be any discussion if this null-related problem should be fixed or
not.
>
> 09.10.2024 18:23, Alexander Kuznetsov wrote:
> > 03.10.2024 12:48, Daniel Gustafsson wrote:
> >> From a quick reading we can only reach there after evaluating an
> >> expression, so can it really be null though? This code hasn't changed
> >> all that much since 2009, if there was a reachable segfault on a null
> >> pointer deref I have a feeling we'd heard about it by now so some extra
> >> care seems warranted to ensure it's not a static analyzer false
> >> positive.
> >
> > Thanks for your response!
> > It seems to me that dereferencing is possible under the following
> > scenario:
> > [...]
> > This entire reasoning is based on the assumption that slot2 can
> > theoretically be NULL, as there is such a check at line 968. Is it
> > possible that no errors have occurred because this condition has always
> > been satisfied and is, perhaps, redundant, or maybe I'm misunderstanding
> > something?
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
Attachments:
[application/pgp-signature] signature.asc (488B, ../../2539287.KokGdZ0ToA@thinkpad-pgpro/2-signature.asc)
download
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Check for TupleTableSlot nullness before dereferencing
2024-10-09 15:23 Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
2024-12-13 08:54 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
@ 2025-07-21 22:20 ` Jacob Champion <[email protected]>
2025-07-22 02:25 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing David Rowley <[email protected]>
1 sibling, 1 reply; 6+ messages in thread
From: Jacob Champion @ 2025-07-21 22:20 UTC (permalink / raw)
To: [email protected]; +Cc: Daniel Gustafsson <[email protected]>; PostgreSQL Developers <[email protected]>; [email protected]; [email protected]; Nikolay Shaplov <[email protected]>
On Fri, Dec 13, 2024 at 12:54 AM Alexander Kuznetsov
<[email protected]> wrote:
> ping. What do you think about reasoning below? Maybe we should consider
> proposing different patch for removing redundant check there?
To move this forward a bit, your reasoning:
> 1. slot2 is NULL at line 968,
> 2. The while loop at line 971 executes once, filling slot1 (slot2 still remains NULL),
> 3. No changes occur to slot2 thereafter, up to line 1003,
> 4. At line 1003, slot2 is swapped with slot1 (assuming numDistinctCols > 0),
> 5. At line 1016, slot1 is dereferenced with conent of slot2 (NULL).
assumes that (numDistinctCols > 0) can be true at the same time that
(slot2 == NULL), but it's not clear to me that this can happen in
practice. See build_pertrans_for_aggref(), where these are assigned.
(A test case producing a NULL dereference would be the fastest way to
prove that it can happen; are you able to construct one?
groupingsets.sql, in the regression tests, hits this code and could
provide a starting point.)
Thanks,
--Jacob
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Check for TupleTableSlot nullness before dereferencing
2024-10-09 15:23 Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
2024-12-13 08:54 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
2025-07-21 22:20 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Jacob Champion <[email protected]>
@ 2025-07-22 02:25 ` David Rowley <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: David Rowley @ 2025-07-22 02:25 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: [email protected]; Daniel Gustafsson <[email protected]>; PostgreSQL Developers <[email protected]>; [email protected]; [email protected]; Nikolay Shaplov <[email protected]>
On Tue, 22 Jul 2025 at 10:20, Jacob Champion
<[email protected]> wrote:
>
> On Fri, Dec 13, 2024 at 12:54 AM Alexander Kuznetsov
> > 1. slot2 is NULL at line 968,
> > 2. The while loop at line 971 executes once, filling slot1 (slot2 still remains NULL),
> > 3. No changes occur to slot2 thereafter, up to line 1003,
> > 4. At line 1003, slot2 is swapped with slot1 (assuming numDistinctCols > 0),
> > 5. At line 1016, slot1 is dereferenced with conent of slot2 (NULL).
>
> assumes that (numDistinctCols > 0) can be true at the same time that
> (slot2 == NULL), but it's not clear to me that this can happen in
> practice. See build_pertrans_for_aggref(), where these are assigned.
I also can't see how this could happen. uniqslot is created in
build_pertrans_for_aggref() when "numDistinctCols > 0", and the swap
of slot1 and slot2 also only occurs when "numDistinctCols > 0". i.e.
the uniqslot will always be allocated when the aggregate has DISTINCT
(unless it's a presorted aggregate, in which case
process_ordered_aggregate_multi() isn't used).
If numDistinctCols > 0 then so is numSortCols > 0 per "numSortCols =
numDistinctCols = list_length(sortlist);" in
build_pertrans_for_aggref().
The code in this area gets a bit of exercise with:
create table ab(a text, b text);
insert into ab values('1','1'),('1','1');
set enable_presorted_aggregate=0;
select string_agg(distinct a,b) from ab;
David
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-07-22 02:25 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17 15:28 [PATCH 2/3] Allow composite types in bootstrap Justin Pryzby <[email protected]>
2024-10-09 15:23 Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
2024-12-13 08:54 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Alexander Kuznetsov <[email protected]>
2025-04-22 07:45 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Nikolay Shaplov <[email protected]>
2025-07-21 22:20 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing Jacob Champion <[email protected]>
2025-07-22 02:25 ` Re: [PATCH] Check for TupleTableSlot nullness before dereferencing David Rowley <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox