docs: add Windows build and run guide / and fix(postgres): resolve pg_dump/pg_restore path cross-platform#63
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughRewrites ChangesCross-platform pg_dump path resolution
GitHub Actions Windows release workflow
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@RambokDev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/domain/postgres/connection.rs`:
- Around line 158-176: The test function respects_pg_bin_dir_override uses
unsafe environment variable manipulation that is not panic-safe: if a panic
occurs after the set_var call on line 168 and before the remove_var cleanup on
line 175, the PG_BIN_DIR environment variable will leak into subsequent tests.
To fix this, create a guard struct that implements the Drop trait to manage the
environment variable lifecycle. The guard should set PG_BIN_DIR in its
constructor and remove it in the Drop implementation, ensuring cleanup happens
automatically regardless of panics. Apply the same panic-safe pattern to the
other test mentioned (around lines 178-198) that also has this issue.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 58a010b2-9792-4c56-8fe8-4d58958348c1
📒 Files selected for processing (3)
.gitignoredocs/WINDOWS_BUILD.mdsrc/domain/postgres/connection.rs
💤 Files with no reviewable changes (1)
- .gitignore
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/windows-release.yml:
- Around line 3-14: The windows-release.yml workflow lacks explicit permission
restrictions and relies on default token permissions which are overly broad. Add
a `permissions:` block at the workflow level (after the `on:` section and before
the `jobs:` section) to explicitly define the minimum required permissions for
the release build. For the `build-windows` job, grant only the necessary
permissions such as `contents: write` for creating releases, and use `read`
permissions for any other operations that need minimal access. This ensures the
workflow adheres to least-privilege security principles.
- Around line 17-18: In the windows-release.yml workflow file, locate the
"Checkout repository" step that uses actions/checkout@v4 and add the
persist-credentials input parameter set to false. This configuration parameter
should be added to the uses directive to prevent the GitHub token from being
persisted in the Git configuration, reducing the security surface area for token
exposure in subsequent workflow steps.
- Line 46: The cargo build command on line 46 does not specify an explicit
binary target, and the subsequent artifact selection logic on lines 57-62
attempts to find portabase-agent.exe but falls back to the first .exe file
found, which can be non-deterministic if multiple binaries exist. Modify the
cargo build --release command to explicitly specify the bin target that is
declared in Cargo.toml using the --bin flag, and update the artifact selection
logic on lines 57-62 to match the explicitly built binary name instead of
relying on heuristic fallback matching. This ensures the correct executable is
always packaged regardless of how many binaries exist in the target directory.
- Line 21: Replace the archived `actions-rs/toolchain@v1` action in the
windows-release.yml workflow with the maintained alternative
`dtolnay/rust-toolchain`. Additionally, scan the entire workflow file for other
unmaintained actions mentioned in the review: replace
`actions/upload-release-asset@v1` with `softprops/action-gh-release@v3` (or use
GitHub CLI), and upgrade `softprops/action-gh-release@v1` to
`softprops/action-gh-release@v3` to ensure all GitHub Actions used in the
workflow are current and actively maintained.
- Line 18: Replace the version tag references in the `uses:` statements
throughout the workflow file with full 40-character commit SHAs instead.
Specifically, update the actions/checkout@v4 reference on line 18, and similarly
update all other version tag references on lines 21, 77, 85, and 93 by replacing
the `@v` format with the complete commit SHA. You can optionally append the
version tag as a comment after the SHA for readability (e.g., uses:
owner/repo@<40-char-sha> # v4). This ensures immutability and prevents tag
retargeting attacks in the release pipeline.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 992922ae-1d5b-4480-8bd3-0c8c5f49b9de
📒 Files selected for processing (2)
.github/workflows/windows-release.ymlsrc/domain/postgres/connection.rs
🚧 Files skipped from review as they are similar to previous changes (1)
- src/domain/postgres/connection.rs
| on: | ||
| workflow_dispatch: | ||
| push: | ||
| tags: | ||
| - 'v*' | ||
| branches: | ||
| - main | ||
| - master | ||
|
|
||
| jobs: | ||
| build-windows: | ||
| runs-on: windows-latest |
There was a problem hiding this comment.
Set explicit least-privilege workflow permissions.
The workflow currently relies on default token permissions, which are broader than needed for a release build job. Add a permissions: block at workflow/job scope and grant only what each step needs (e.g., contents: write for release, minimal read elsewhere).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/windows-release.yml around lines 3 - 14, The
windows-release.yml workflow lacks explicit permission restrictions and relies
on default token permissions which are overly broad. Add a `permissions:` block
at the workflow level (after the `on:` section and before the `jobs:` section)
to explicitly define the minimum required permissions for the release build. For
the `build-windows` job, grant only the necessary permissions such as `contents:
write` for creating releases, and use `read` permissions for any other
operations that need minimal access. This ensures the workflow adheres to
least-privilege security principles.
Source: Linters/SAST tools
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
Disable credential persistence in checkout.
actions/checkout should set persist-credentials: false in this release workflow to reduce token exposure surface in subsequent steps/artifacts.
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/windows-release.yml around lines 17 - 18, In the
windows-release.yml workflow file, locate the "Checkout repository" step that
uses actions/checkout@v4 and add the persist-credentials input parameter set to
false. This configuration parameter should be added to the uses directive to
prevent the GitHub token from being persisted in the Git configuration, reducing
the security surface area for token exposure in subsequent workflow steps.
Source: Linters/SAST tools
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "windows-release.yml" -type fRepository: Portabase/agent
Length of output: 99
🏁 Script executed:
cat -n ./.github/workflows/windows-release.ymlRepository: Portabase/agent
Length of output: 4256
🌐 Web query:
GitHub Actions security best practices pinning actions to commit SHA
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is a critical security best practice designed to protect against supply chain attacks [1][2][3]. When you reference an action using a branch name or version tag (e.g., @v4 or @main), you are using a mutable reference that can be modified or "retargeted" by the action owner or an attacker who gains control of the repository [1][4][5]. Because tags can be moved to point to new, potentially malicious code, workflows using them are vulnerable to unexpected changes [2][6]. Key security benefits and practices include: Immutability: A full-length commit SHA uniquely identifies a specific state of an action's codebase [3]. Because it is content-addressed, the code cannot be altered once pinned, providing a guarantee that your workflow will execute the exact same logic every time [4][6][3]. Mitigating Supply Chain Attacks: Pinning prevents "tag retargeting" attacks, where malicious code is pushed to an existing tag [2][7]. By using a SHA, you ensure that you are not affected by unauthorized changes to an action's release tags [6][5]. Operational Policies: GitHub supports organization-level policies that can enforce SHA pinning [1][8]. When enabled, workflows attempting to use non-pinned actions will fail, forcing compliance across all repositories in an organization [8][4][2]. Maintenance with Automation: Pinning creates a maintenance burden, as you must manually update SHAs to receive security patches or features [2][5]. To manage this, use automated dependency management tools like Dependabot or Renovate [2][7][6]. These tools can monitor for updates and open pull requests to update your pinned SHAs [2][7][5]. Best Practice for Implementation: - Always use the full 40-character commit SHA [1][5]. - Include the version tag as a comment in your workflow file (e.g., uses: owner/repo@sha # v4.0.0) [2][7]. This makes the dependency human-readable and helps tools like Renovate identify which version to update to [2][5]. - If you maintain shared actions, pin any internal sub-actions to full commit SHAs to prevent breaking the workflows of users who have enforced SHA-pinning policies [4]. - Treat only GitHub-owned actions (under the actions/ namespace) as potentially safe to use with tags, though SHA pinning remains the most secure standard for all dependencies [5].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 3: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://safeguard.sh/resources/blog/how-to-pin-github-actions-to-shas-correctly
- 6: https://nearform.com/insights/why-you-should-pin-your-github-actions-by-commit-hash/
- 7: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 8: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin all uses: actions to commit SHAs instead of version tags.
Lines 18, 21, 77, 85, and 93 reference actions by version tag only (e.g., @v4, @v1), which are mutable references vulnerable to tag retargeting attacks. For a release pipeline, use full 40-character commit SHAs to ensure immutability and prevent supply-chain drift. Optionally include the version tag as a comment (e.g., uses: owner/repo@<sha> # v4.0.0) for readability, and use Dependabot or Renovate to automate SHA updates.
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/windows-release.yml at line 18, Replace the version tag
references in the `uses:` statements throughout the workflow file with full
40-character commit SHAs instead. Specifically, update the actions/checkout@v4
reference on line 18, and similarly update all other version tag references on
lines 21, 77, 85, and 93 by replacing the `@v` format with the complete commit
SHA. You can optionally append the version tag as a comment after the SHA for
readability (e.g., uses: owner/repo@<40-char-sha> # v4). This ensures
immutability and prevents tag retargeting attacks in the release pipeline.
Source: Linters/SAST tools
| run: | | ||
| # Ensure the environment variable is present for this step | ||
| if (-Not $env:OPENSSL_DIR) { Write-Host "OPENSSL_DIR not set, printing env for debugging"; Get-ChildItem Env: | ForEach-Object { Write-Host $_ } } | ||
| cargo build --release |
There was a problem hiding this comment.
Make artifact selection deterministic against the declared Rust bin target.
Line 57 prefers portabase-agent.exe, but Cargo.toml declares [[bin]] name = "app". The fallback to “first .exe” can package the wrong executable if multiple binaries exist. Build and package a specific bin explicitly.
Suggested fix
- - name: Build (cargo release)
+ - name: Build (cargo release)
shell: pwsh
env:
# Cargo / openssl-sys will pick up OPENSSL_DIR from the environment
OPENSSL_DIR: ${{ env.OPENSSL_DIR }}
run: |
# Ensure the environment variable is present for this step
if (-Not $env:OPENSSL_DIR) { Write-Host "OPENSSL_DIR not set, printing env for debugging"; Get-ChildItem Env: | ForEach-Object { Write-Host $_ } }
- cargo build --release
+ cargo build --release --bin app
@@
- # Find the built executable. Prefer an explicit portabase-agent.exe, fall back to first exe in target/release
- $exe = "target\release\portabase-agent.exe"
- if (-not (Test-Path $exe)) {
- $first = Get-ChildItem -Path target\release -Filter *.exe | Select-Object -First 1
- if ($first) { $exe = $first.FullName }
- }
+ # Use the explicit release binary declared in Cargo.toml
+ $exe = "target\release\app.exe"Also applies to: 57-62
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/windows-release.yml at line 46, The cargo build command on
line 46 does not specify an explicit binary target, and the subsequent artifact
selection logic on lines 57-62 attempts to find portabase-agent.exe but falls
back to the first .exe file found, which can be non-deterministic if multiple
binaries exist. Modify the cargo build --release command to explicitly specify
the bin target that is declared in Cargo.toml using the --bin flag, and update
the artifact selection logic on lines 57-62 to match the explicitly built binary
name instead of relying on heuristic fallback matching. This ensures the correct
executable is always packaged regardless of how many binaries exist in the
target directory.
|
@RambokDev |
|
Hi @tobfel, Regards 😉 |
…, and the trigger in windows-release.yml
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/domain/postgres/connection.rs (1)
93-99:⚠️ Potential issue | 🟠 Major | ⚡ Quick winValidate candidate directories against both client binaries.
The resolver currently returns a directory when
pg_dumpexists, but restore also depends onpg_restorefrom the same directory. This can pass resolution and still fail at runtime during restore.Suggested fix
- if let Some(found) = candidates.into_iter().find(|p| pg_dump_exists_in(p)) { + if let Some(found) = candidates.into_iter().find(|p| pg_clients_exist_in(p)) { return found; } - if let Some(dir) = find_pg_dump_in_path() { + if let Some(dir) = find_pg_dump_in_path().filter(|d| pg_clients_exist_in(d)) { return dir; } @@ pub(crate) fn pg_dump_exists_in(dir: &std::path::Path) -> bool { dir.join(pg_dump_binary_name()).is_file() } + +fn pg_restore_binary_name() -> &'static str { + if cfg!(target_os = "windows") { + "pg_restore.exe" + } else { + "pg_restore" + } +} + +fn pg_restore_exists_in(dir: &std::path::Path) -> bool { + dir.join(pg_restore_binary_name()).is_file() +} + +fn pg_clients_exist_in(dir: &std::path::Path) -> bool { + pg_dump_exists_in(dir) && pg_restore_exists_in(dir) +}Also applies to: 112-114
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/domain/postgres/connection.rs` around lines 93 - 99, The validation logic in the find operation is incomplete because it only checks for the existence of pg_dump but not pg_restore, even though both binaries are required from the same directory for restore operations. Update the candidate selection in the find call (where pg_dump_exists_in is checked) to also validate that pg_restore exists in the same directory. Apply the same dual validation to the result returned from find_pg_dump_in_path() at the location marked "Also applies to". Either enhance pg_dump_exists_in to check for both binaries or create a separate validation function that confirms both pg_dump and pg_restore are present in the candidate directory before returning it.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/windows-release.yml:
- Around line 7-8: The tag glob pattern `[0-9]+.[0-9]+.[0-9]+` in the
windows-release.yml workflow file uses regex syntax instead of GitHub Actions
glob syntax, which will not match semantic version tags like 1.2.3. Replace this
pattern with a valid glob pattern such as `v[0-9]*.[0-9]*.[0-9]*` (if your tags
are prefixed with `v`) or adjust it to match your actual tag naming convention,
keeping in mind that `*` matches zero or more characters in glob patterns, not
`+` which is treated as a literal character.
In `@docker-compose.yml`:
- Line 22: The EDGE_KEY environment variable in the docker-compose.yml file
contains a hardcoded base64-encoded credential payload that includes a
masterKeyB64, which represents a security risk when committed to source control.
Replace the hardcoded EDGE_KEY value with environment variable interpolation
(using the standard docker-compose syntax for environment variables) so that the
actual credential is provided at runtime rather than being versioned.
Additionally, ensure the exposed credential is rotated to prevent unauthorized
access.
---
Outside diff comments:
In `@src/domain/postgres/connection.rs`:
- Around line 93-99: The validation logic in the find operation is incomplete
because it only checks for the existence of pg_dump but not pg_restore, even
though both binaries are required from the same directory for restore
operations. Update the candidate selection in the find call (where
pg_dump_exists_in is checked) to also validate that pg_restore exists in the
same directory. Apply the same dual validation to the result returned from
find_pg_dump_in_path() at the location marked "Also applies to". Either enhance
pg_dump_exists_in to check for both binaries or create a separate validation
function that confirms both pg_dump and pg_restore are present in the candidate
directory before returning it.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: de68ab9a-ebb9-44cd-8e69-dd92a786b73c
📒 Files selected for processing (7)
.github/workflows/windows-release.yml.gitignoredocker-compose.ymlsrc/domain/postgres/connection.rssrc/domain/postgres/mod.rssrc/settings.rssrc/tests/domain/postgres.rs
✅ Files skipped from review due to trivial changes (1)
- .gitignore
|
Hi @tobfel, That is marged, and will be added to main ASAP. Thanks for you contribution to Portabase |
2 participants
Commit 1
Commit message
fix(postgres): resolve pg_dump/pg_restore path cross-platform
select_pg_pathwas hardcoded to the Debian/Ubuntu package layout(
/usr/lib/postgresql/<major>/bin), which doesn't exist on Windows ormacOS. This broke the agent on Windows entirely, since the PostgreSQL
binaries (
pg_dump,pg_restore, ...) could never be located.This adds:
PG_BIN_DIRenvironment variable to override detectionentirely (useful for portable/non-standard installs and CI).
Homebrew/Postgres.app on macOS, Debian/Ubuntu and RPM-based distros
on Linux).
PATHlookup forpg_dumpas a further fallback.The function still always returns a
PathBuf(never panics), matchingprior behavior for callers that don't yet handle a "not found" case.
Commit 2
Commit message
docs: add Windows build and run guide
Adds
docs/WINDOWS_BUILD.md, covering:openssl-sysvendored build failure on Windowsby using a prebuilt OpenSSL via vcpkg,
using the community
redis-windowsdistribution),an optional
.envfile),portabase-agent.exeinstead of the current generic
app.exe.This documents the steps that were actually needed to get a working
local Windows build/run, complementing the
select_pg_pathfix inthis PR.
Pull Request
Title
fix(postgres): make
select_pg_pathcross-platform + Windows build docs (fixes Windows builds)Description
Problem
select_pg_pathinsrc/domain/postgres/connection.rsis hardcoded to:This is the Debian/Ubuntu package path and does not exist on Windows or
macOS. As a result, the agent cannot locate
pg_dump/pg_restoreonthose platforms — backup/restore operations fail even though the
project itself compiles fine on Windows (after working around the
unrelated
openssl-sysvendored build requirement).Fix
select_pg_pathnow resolves the PostgreSQLbindirectory using thefollowing order:
PG_BIN_DIRenvironment variable, if set — explicit overridefor non-standard or portable installs.
C:\Program Files\PostgreSQL\<major>\binand the(x86)variant (default EDB installer paths)./opt/homebrew/...and/usr/local/opt/...)and Postgres.app.
/usr/pgsql-<major>/binRPM-based layout.PATHlookup forpg_dump(pg_dump.exeon Windows) as afurther fallback.
function's signature and panic-free behavior are unchanged for
existing callers.
Each candidate is verified to actually contain a
pg_dumpbinarybefore being returned, rather than blindly constructing a path string.
Testing
Added unit tests for:
PG_BIN_DIRoverride (including that it takes precedenceregardless of the requested version),
pg_dumpbinary name,pg_dump_exists_inreturningfalsefor a non-existent directory.These tests deliberately avoid asserting on whether a real PostgreSQL
install is found via the default search paths or
PATH, since thatdepends on what's installed on the machine running the tests (CI
runners and developer machines differ, and may have any PostgreSQL
major version installed, or none) — an earlier draft of these tests
asserted on that and was flaky for exactly this reason on a Windows
machine with PostgreSQL 16 installed.
PG_BIN_DIRis used to maketest behavior deterministic instead.
Also note:
std::env::set_var/remove_varareunsafeas of the 2024edition (process-global mutation, UB if raced across threads). Since
cargo testruns tests in parallel by default, the env-mutating testsare serialized via a
Mutexto avoid both real races and a poisonedmutex cascading into unrelated test failures.
Manually verified end-to-end on Windows 11 with a standard EDB
PostgreSQL 16 install (no
PG_BIN_DIRneeded — picked up automaticallyvia the default path) and via
PG_BIN_DIRoverride pointing at aportable PostgreSQL distribution.
cargo testpasses for this module;remaining failures in the full test suite on Windows are pre-existing
and unrelated — they come from Testcontainers/
bollardfailing toreach a Docker daemon (
select_pg_pathtests don't touch Docker atall).
Windows build/run documentation
Also added
docs/WINDOWS_BUILD.md, written up from a successful localWindows build/run, covering:
openssl-sysvendoredfeature failing to build on Windows(
nmake-related issue) and using a prebuilt OpenSSL via vcpkginstead, which worked reliably.
redis-windows
distribution (no official Windows Redis build exists).
startup script.
app.exetoportabase-agent.exe(via an explicit[[bin]] name =in
Cargo.toml) for clarity — left as a recommendation rather thanapplied directly in this PR, since I don't have visibility into the
full
Cargo.toml/main.rsand didn't want to guess at a renamethat might conflict with existing tooling/CI.
from a
.envfile via thedotenvycrate, for easier localdevelopment on Windows — also left as a recommendation pending
maintainer input, since
src/services/config.rslikely alreadyowns configuration loading and might be a better place for this
than a raw
dotenvy::dotenv()call inmain().Notes / open questions for maintainers
PathBuf, never an error" behavior toavoid changing the function signature and downstream call sites in
this PR. Happy to follow up with a
Result/Option-based API ifpreferred — let me know and I'll adjust.
(e.g. Arch, NixOS); included the most common ones. Open to adding
more candidates if maintainers know of others worth covering.
Summary by CodeRabbit
New Features
PATHlookup.PG_BIN_DIRenvironment variable configuration option to override the default PostgreSQL binary directory.Chores