Backend crashes on DDL statements longer than ~1100 bytes (self-compiled 2.1.8, PG 17.10)

Reproduce the length threshold on the self-compiled pgactive 2.1.8 node using the SQL examples, then start by reading src/pgactive_ddlrep_truncate.c and tracing the broader DDL path. Compare behavior with pgactive.skip_ddl_replication enabled and verify that long DDL no longer closes the backend, while shorter statements and the provided control cases continue to work.

Summary

On a self-compiled pgactive 2.1.8 node, any DDL statement whose text exceeds roughly 1100 bytes crashes the backend. The connection is closed (server closed the connection unexpectedly), the postmaster survives, and nothing is logged by the server.

The content of the statement is irrelevant — only its length matters.

Reproduction

On a database with the pgactive extension installed, as a superuser:

-- passes
CREATE OR REPLACE FUNCTION public.t() RETURNS int LANGUAGE plpgsql AS $f$
BEGIN
-- <1000 'x' characters>
  RETURN 1;
END; $f$;

-- crashes the backend
CREATE OR REPLACE FUNCTION public.t() RETURNS int LANGUAGE plpgsql AS $f$
BEGIN
-- <1100 'x' characters>
  RETURN 1;
END; $f$;

The function body is meaningless on purpose: a comment is enough to trigger it. Measured threshold: 1080 bytes passes, 1100 bytes crashes (total statement length). The boundary is not sharp, which is what one would expect from a memory overflow.

What it is not

Verified by elimination:

The only pgactive event trigger present is pgactive_truncate_trigger_add (evtenabled = 'A'). Reading src/pgactive_ddlrep_truncate.c, that handler returns early for anything that is not CREATE TABLE, so the crash likely happens elsewhere in the DDL path.

Environment

Same extension version and same PostgreSQL version on both sides — only the build differs. A third database without pgactive accepts the identical DDL without problems.

pgactive.skip_ddl_replication = on on the affected node.

Impact

Any schema migration containing a moderately large DDL statement — a function with a non-trivial body, a wide CREATE TABLE, a complex view — fails on the node. Because the failure surfaces as a dropped connection with no server-side log entry, the length limit is very hard to guess: it took us several hours and a bisection on statement size to find it.

Transactions roll back cleanly, so no corruption was observed.

Notes

Happy to provide more detail, run additional tests on the affected node, or try a build with different compiler flags if that would help narrow it down.