Re: Row pattern recognition

Hi hackers,

I ran Valgrind memcheck against the RPR (Row Pattern Recognition)
implementation
to verify there are no memory issues introduced by the new Row Pattern
Recognition feature.

== Test Environment ==

- PostgreSQL: 19devel (master branch)
- Valgrind: 3.22.0
- Platform: Linux x86_64 (RHEL 9)
- Tests executed: rpr.sql

== Executive Summary ==

+----------------------------------------------------------+
| RPR Implementation: NO MEMORY ISSUES DETECTED |
+----------------------------------------------------------+

All detected leaks originate from existing PostgreSQL core components.
No RPR-related functions appear in any leak stack traces.

== Backend Process 541453: Itemized Leak Analysis ==

Total: 37 bytes definitely lost in 1 block, 1 unique leak context

+================================================================================+
| # | Bytes | Blocks | Allocator | Root Cause | RPR? | Verdict
|
+================================================================================+
| 1 | 37 | 1 | strdup | Postmaster init | NO | HARMLESS
|
+================================================================================+
TOTAL: 37 bytes in 1 block
RPR-RELATED LEAKS: 0

== RPR Verification ==

All leak stack traces were examined. Key functions NOT present:

- ExecInitWindowAgg (RPR path)
- row_pattern_initial, row_pattern_final
- Any function from src/backend/executor/nodeWindowAgg.c (RPR code paths)
- Any RPR-related parser functions (PATTERN, DEFINE)

The RPR tests exercised window functions with PATTERN, DEFINE clauses
(e.g., PATTERN (START UP+ DOWN+)), yet none of these code paths appear in
leaks.

== Process Summary ==

+--------+----------------+-----------------+----------+--------------------+
| PID | Type | Definitely Lost | Errors | Notes
|
+--------+----------------+-----------------+----------+--------------------+
| 541303 | postmaster | 37 bytes | 1 | strdup at startup
|
| 541453 | backend | 37 bytes | 12 | See above analysis
|
| 541314 | checkpointer | 37 bytes | 1 | strdup at startup
|
| 541315 | bgwriter | 37 bytes | 1 | strdup at startup
|
| 541316 | walwriter | 37 bytes | 1 | strdup at startup
|
| 541317 | autovacuum | 37 bytes | 1 | strdup at startup
|
| 541318 | logical rep | 37 bytes | 1 | strdup at startup
|
| 541319 | syslogger | 37 bytes | 1 | strdup at startup
|
| Others | aux workers | 37 bytes each | 1 each | strdup at startup
|
+--------+----------------+-----------------+----------+--------------------+

== Possibly Lost (LLVM JIT) ==

Additionally, ~16KB in ~165 blocks reported as "possibly lost" from LLVM
JIT:
- llvm::MDTuple, llvm::User allocations
- Origin: llvm_compile_expr -> jit_compile_expr -> ExecReadyExpr
- These are LLVM's internal caches, not PostgreSQL leaks

== Other Memory Errors ==

+--------------------------------------------------------------------------+
| NO memory access errors detected: |
| - Invalid read/write: 0 |
| - Use of uninitialized value: 0 |
| - Conditional jump on uninitialized value: 0 |
| - Syscall param errors: 0 |
| - Overlap in memcpy/strcpy: 0 |
+--------------------------------------------------------------------------+

Suppressed errors (via valgrind.supp):
- 541453 (backend): 46 errors from 3 contexts suppressed
- Other processes: ~0 errors each suppressed

Suppression rules in valgrind.supp (12 categories):
1. Padding - write() syscalls with uninitialized struct padding
2. CRC - CRC32 calculation on padded buffers
3. Overlap - memcpy overlap in bootstrap/relmap
4. glibc - Dynamic loader internals
5. Regex/Pattern - RE_compile_and_cache, patternsel
6. Planner - query_planner memcpy overlap
7. Cache - RelCache, CatCache, TypeCache possible leaks
8. XLogReader - WAL reader allocations
9. Parallel - ParallelWorkerMain allocations
10. AutoVacuum - AutoVacWorkerMain allocations
11. GUC/Backend - set_config_option, InitPostgres
12. PL/pgSQL - plpgsql_compile, SPI_prepare, CachedPlan

All suppressed errors are known, harmless PostgreSQL behaviors.
See attached valgrind.supp for details.

== Conclusion ==

The RPR implementation introduces NO memory leaks. All detected issues
are pre-existing PostgreSQL behaviors related to:

1. Postmaster startup allocations
2. LLVM JIT internal caching

These are by-design patterns that trade minimal memory for performance.

== Files Attached ==

- valgrind.supp: Suppression file used for this test
- 541303.log: Postmaster log
- 541453.log: Backend log with full leak details (56KB)
- 5413xx.log: Auxiliary process logs

--
Regards

2025년 12월 23일 (화) PM 10:28, Tatsuo Ishii <ishii(at)postgresql(dot)org>님이 작성:

> Attached are the v36 patches, just for rebasing.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>