Repository navigation
memory debugging functionality #5
Description
I'm not sure the best way to incorporate this but I think xpg should have memory debugging functionality build in. Thinking stuff like Valgrind, asan/ubsan. asan/ubsan require a custom build whereas valgrind can be attached to any binary. Currently xpg has a postgres build matrix of version (12-19, 8 versions total), and cassert for a total of 16 builds. If we were to add a third matrix dimension for a asan/ubsan build this would explode to 32 builds, not ideal but also not sure how else to handle this. Given this build explosion maybe it would make sense to incorporate valgrind testing first, that said not sure how this would work. Ideally after testing it would exit with return code non 0 if any memory errors were found and thus fail any test, but only for the extension.
Curious what you think.
Activity
AndrewJackson2020 commentedon Sep 29, 2026
Another issue here is that while valgrind does not require an extra dimension of builds, it only works on linux and not macOS. Not sure exactly how to handle this with nix and if that makes it easer or harder to incorporate here.
steve-chavez commentedon Sep 30, 2026
I agree in that memory debugging would be useful. I think we could just have the same build for cassert and asan or ubsan. Would there be any downsides to that?
AndrewJackson2020 commentedon Sep 30, 2026
Some stuff I can think of:
[0] https://github.com/pgbouncer/pgbouncer/blob/7d38761c8f6c757238fde9f942cf9fe0cd272ae3/.github/workflows/pgbouncer-ci.yml#L172
mkaruza commentedon Oct 2, 2026
I don't think there is any benefit of running all version with USAN/UBSAN enabled. As @AndrewJackson2020 mentioned it should be enough to run on "default"/some version.
AndrewJackson2020 commentedon Nov 3, 2026
Closed due to #14