From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Possible NULL dereferencing (src/backend/tcop/pquery.c) |
Date: | 2020-06-26 14:31:18 |
Message-ID: | CAEudQAppKDbMi=mijz9ayFpj4x0VQg9ZcHVK2F90VKM7ozqyfA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Per Coverity.
Perhaps it is excessive caution.
Probably assertion check has already caught all possible errors.
But, redundancy may not cost as much and is worth it.
1.Assertion check
/* Caller messed up if we have neither a ready query nor held data. */
Assert(queryDesc || portal->holdStore);
But in release, if QueryDesc is NULL and portal->holdStore is NULL too,
when Call PushActiveSnapshot *deference* NULL check can happen.
2. if (portal->atEnd || count <= 0) is True
No need to recheck count against FETCH_ALL.
Is it worth correcting them?
regards,
Ranier Vilela
Attachment | Content-Type | Size |
---|---|---|
fix_null_deference_pquery.patch | application/octet-stream | 1.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-06-26 14:44:14 | Re: Default setting for enable_hashagg_disk |
Previous Message | Andrew Dunstan | 2020-06-26 14:24:33 | Re: pg_dump bug for extension owned tables |