Request a Demo
Home   >   mailing lists

Re: Row pattern recognition - Mailing list pgsql-hackers

From Henson Choi
Subject Re: Row pattern recognition
Date
Msg-id CAAAe_zAWxo__deoq34Jrk=3Pq6dPXUD3Ppoxs+-kuLGfVK66aQ@mail.gmail.com
Whole thread Raw
In response to Re: Row pattern recognition  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
Tree view
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@postgresql.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
Attachment

pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: Planner : anti-join on left joins
Next
From: Pavel Stehule
Date:
Subject: Re: Patch: dumping tables data in multiple chunks in pg_dump