[Segmentation Fault] when creating graph node whose vertex label table has GENERATED ALWAYS columns

[bilalsp]

Describe the bug
Adding a GENERATED ALWAYS AS (...) STORED column to a vertex label table (_ag_label_vertex child table) causes a segmentation fault (signal 11) during Cypher CREATE / SET operations.
The crash occurs in the vertex creation path (likely during heap_insert in the executor).

How are you accessing AGE (Command line, driver, etc.)?
Directly via cypher() SQL function (IN psql client).

What data setup do we need to do?

-- 1. Create graph and label
SELECT create_graph('age_bug');
SELECT create_vlabel('age_bug', 'Product');

-- 2. Add generated column (this triggers the bug)
ALTER TABLE age_bug."Product"
	ADD COLUMN category VARCHAR(25) GENERATED ALWAYS AS (agtype_access_operator(properties, '"category"')) STORED;

What is the necessary configuration info needed?

• [e.g. Installed PostGIS]

What is the command that caused the error?

SELECT * FROM cypher('age_bug', $$
   CREATE (p:Product {category: 'disk', type: 'M1234', version: 1})
   RETURN p
$$) AS (p agtype);

ERROR: 
psql client log: 
SQL Error [08006]: An I/O error occurred while sending to the backend.

server log: 
LOG:  server process (PID XXX) was terminated by signal 11: Segmentation fault
DETAIL:  Failed process was running: [the cypher CREATE query]
LOG:  terminating any other active server processes
FATAL:  the database system is in recovery mode
FATAL:  the database system is in recovery mode
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted; last known up at  XXXX
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  invalid record length at 5716/4C635DA8: wanted 24, got 0
LOG:  redo is not required
LOG:  checkpoint starting: end-of-recovery immediate wait
LOG:  checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.006 s, sync=0.003 s, total=0.017 s; sync files=3, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
LOG:  database system is ready to accept connections
FATAL:  database "template0" is not currently accepting connections
LOG:  background worker "autoprewarm worker" (PID XXX) exited with exit code 1

Even though MATCH query does NOT RAISE ANY error

SELECT * FROM cypher('age_bug', $$
   MATCH (p:Product {category: 'disk', type: 'M1234', version: 1})
   RETURN p
$$) AS (p agtype);

Expected behavior
AGE should support standard PostgreSQL features like generated columns on label TABLES

Environment (please complete the following information):

• AGE Version: release/PG15/1.5.0
• PostgreSQL Version: PostgreSQL 15.8 (Debian 15.8-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
• OS: Linux

Additional context
Add any other context about the problem here.

[bilalsp]

Hi @gregfelice

We're currently blocked by the segfault on GENERATED ALWAYS columns in vertex table and wanted to check whether you have plan to fix this issue anytime soon. If not, we would appreciate any guidance on a possible workaround. thanks!!!

[gregfelice]

On it

[gregfelice]

Thanks for the clear reproducer, @bilalsp — that made this quick to pin down.

Root cause. AGE's CREATE/MERGE/SET paths build the insert/update tuple slot from the full label-table descriptor but only populate the columns AGE manages (id/properties for vertices, id/start_id/end_id/properties for edges). Your GENERATED ALWAYS ... STORED column is an extra attribute AGE never initialized, so heap_form_tuple() read the uninitialized slot entry and segfaulted dereferencing garbage. The same happens for a plain added column, and on SET as well as CREATE.

Fix (PR incoming):

• The entity slot is now null-initialized before AGE fills its own columns, so any column AGE doesn't manage defaults to NULL instead of stale memory.
• Stored generated columns are computed via ExecComputeStoredGenerated() before the tuple is materialized — on insert (CREATE/MERGE) and recomputed on update (SET) — matching PostgreSQL semantics.

Verified against your exact repro plus a new regression test: your case now works and the generated column is correctly computed:

CREATE (p:Product {category: 'disk', ...})  -->  "Product".category = 'disk'
MATCH (p:Product {category:'disk'}) SET p.category='ssd'  -->  recomputes to 'ssd'

One caveat worth flagging: on SET, AGE rebuilds the row from id/properties, so a generated column recomputes correctly, but a plain (non-generated) column would be reset to NULL. If you need a value preserved across updates, use a GENERATED ... STORED column derived from properties (as in your example) rather than a plain column — that path is fully supported.

Workaround until the PR lands: if you can't wait, computing category at query time via an expression index instead of a stored generated column avoids the crash:

CREATE INDEX ON age_bug."Product" ((agtype_access_operator(properties, '"category"')));

I'll link the PR here shortly.

[gregfelice]

PR opened: #2458