Horton

Re: Check for tuplestorestate nullness before dereferencing

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, kuznetsovam@altlinux.org, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, nickel@altlinux.org, egori@altlinux.org
Date: 2024-10-17T23:28:22Z
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

On Tue, 15 Oct 2024 at 05:21, Alena Rybakina <a.rybakina@postgrespro.ru> wrote:
> As I see it, node->eflags can be zero if it passes the output of a
> subquery, during the initialization of the Material node execution, and
> when the subquery is rescanned.

Do you have a test case that calls Material with zero eflags?  I tried
adding Assert(node->eflags != 0) to ExecMaterial() and nothing failed.

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.

David