Horton

Re: Check for tuplestorestate nullness before dereferencing

Nikolay Shaplov <dhyan@nataraj.su>

View thread
From: Nikolay Shaplov <dhyan@nataraj.su>
To: Alena Rybakina <a.rybakina@postgrespro.ru>, pgsql-hackers@lists.postgresql.org
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, kuznetsovam@altlinux.org, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, nickel@altlinux.org, egori@altlinux.org, David Rowley <dgrowleyml@gmail.com>
Date: 2025-04-22T11:16:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Create infrastructure for 'MinimalTuple' representation of in-memory

  2. Teach nodeSort and nodeMaterial to optimize out unnecessary overhead

В письме от пятница, 18 октября 2024 г. 02:28:22 MSK пользователь David Rowley 
написал:

> It would be good to know if the optimisation added in d2c555ee5 ever
> applies with today's code. If it does apply, we should likely add a
> test case for it and if it never does, then we should just remove the
> optimisation and always create the tuplestore when it's NULL.

That's sounds reasonable. It looks like that removing "node->eflags != 0" check 
is more logical then adding not null check.

> If it does apply, we should likely add a test case for it 

Do you have any idea how to test it?


-- 
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su