Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements - Mailing list pgsql-bugs

From Anthonin Bonnefoy
Subject Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements
Date
Msg-id CAO6_XqpJkQcvMH_2voBugKFEd8YsVD6GnzizCw6EbkNkMFHtrA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
On Fri, Jun 13, 2025 at 1:51 AM Michael Paquier <michael@paquier.xyz> wrote:
> - About the tests we could do to validate more in depth the locations
> and lengths assigned to the parsed node without relying on PGSS and
> EXPLAIN, which will support never support the full range of things
> like views.  I was wondering about the addition of a test module that
> plugs into one or more hooks (only the post-parse one should be
> enough), where we simply print the Nodes generated to a string using
> the facility in src/backend/nodes/print.c.  It would be then possible
> to filter the output generated with some regex magic to print the
> fields we want to check.  That would work for the CREATE VIEW case,
> for example, and it could be used for other things than just the
> statement length and/or locations set in a gIven Node.

Agree on the tests. Having a test module that dumps the parse tree in
an usable way for the tests was definitely something I had in mind.
Relying on PGSS to test parse behaviour definitely has its limit.



pgsql-bugs by date:

Previous
From: Laurence Parry
Date:
Subject: Re: BUG #18942: walsender memory allocation failure adding snapshot and invalidations to logical replica w/PG 16.9
Next
From: Dilip Kumar
Date:
Subject: Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.