Debian Patches

Status for pljs/1.0.3-2

Patch Description Author Forwarded Bugs Origin Last update
0001-Performance-updates.patch [PATCH 1/2] Performance updates.
Benchmarking originally showed fairly high memory usage and a slow garbage
collection schedule when creating 1000 contexts. To avoid this, a garbage
collection cycle was put into place after each function execution. This
solved the memory bloat, but slowed down function calls.

I decided to revisit that decision.

Memory limits were an arbitrary 256MB when the concept was put into place
in plv8 in 2019, and 512MB is a decent default with modern hardware. It
can still be changed to 256MB with a GUC if desired.

The benchmark was able to trigger an out of memory issue, but under very
artificial conditions:

* 1000 roles, and thus quickjs contexts were being created
* Each context carries an allocation of 190kb on MacOS (untested on Linux)

Even though the roles are deleted, there is no mechanism for postgres to tell
pljs this, and those contexts essentially become zombies in the cache.

Since the benchmark is an extremely artifical (and meant specifically to
test the startup time of pljs contexts), it is unlikely that this behavior
will be able to be triggered in production. At worst case, a memory limit
is hit, and the limit needs to be increased via the GUC.

Thus garbage collection is left to run when memory pressure exists, rather
with every function execution, and more memory can be allocated to slow
memory pressure by default.

This speeds up contex creation and function calls slightly, and speeds up
the artificial context creation significantly.		 Jerry Sievert <code@legitimatesounding.com> no 2025-09-10
0002-Updates-SRF-handling-and-timeouts-for-array-spread-t.patch [PATCH 2/2] Updates SRF handling and timeouts for array spread tests
The RISC-V architecture exposed two issues:

1. There was the possibility of undefined behaviour in Set Returing Functions (SRF), which had appeared to be transient, but was consistent in the RISC-V architecture. The SRF return functionality was seperated by use case and cleaned up. This code is a good target for refactoring and simplification in the future. In addition, some explicit memory deallocation was added, which should help memory pressure in large object or large array returns.
2. I had arbitrarily chosen a timeout of 5 seconds for the `array_spread` tests (these are plv8 regression tests that show sane handling for a known V8 issue, QuickJS should always pass these tests), some architectures can take longer than that, so the timout interrupt was triggered instead of the out of memory error. I've raised this to 60 seconds to help the execution speed differences. Hopefully this will be enough, but it can be adjusted as needed from this arbitary number.		 Jerry Sievert <code@legitimatesounding.com> no 2025-10-19
quickjs.patch no

All known versions for source package 'pljs'

Links