Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements
От | Anthonin Bonnefoy |
---|---|
Тема | Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements |
Дата | |
Msg-id | CAO6_XqpJkQcvMH_2voBugKFEd8YsVD6GnzizCw6EbkNkMFHtrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements (Michael Paquier <michael@paquier.xyz>) |
Список | 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 по дате отправления: