DOC: confusing stmt on pgbouncer support with no reasoning #78

Closed
opened 2026-02-21 17:17:08 -05:00 by yindo · 7 comments
Owner

Originally created by @ardentperf on GitHub (Jun 11, 2025).

#843 added a statement that pgbouncer isn't supported, without any indication of why this statement was made or what kind of problem was encountered. pgbouncer is very widely used and if some problem was encountered then it's far more likely due to misconfiguration somewhere, than actual lack of support. this statement is causing some confusion in my org and would be helpful to either revert it or provide some explanation why it was added. outside of things like raw physical replication, highly unusual to have complete outright incompatibility with pgbouncer.

Originally created by @ardentperf on GitHub (Jun 11, 2025). #843 added a statement that pgbouncer isn't supported, without any indication of why this statement was made or what kind of problem was encountered. pgbouncer is very widely used and if some problem was encountered then it's far more likely due to misconfiguration somewhere, than actual lack of support. this statement is causing some confusion in my org and would be helpful to either revert it or provide some explanation why it was added. outside of things like raw physical replication, highly unusual to have complete outright incompatibility with pgbouncer.
yindo closed this issue 2026-02-21 17:17:08 -05:00
Author
Owner

@langchain-infra commented on GitHub (Jun 11, 2025):

LangSmith self hosted today doesn't support pgbouncer due to the way we use the connection strings in our migrations. The initial pr name was a typo but has been rectified. Correct you can probably run it in session mode but its not something we have tested. What confusion is this causing in your org? In a self-hosted environment we want to limit the blast radius of things we support/have to guide people on configuring.

@langchain-infra commented on GitHub (Jun 11, 2025): LangSmith self hosted today doesn't support pgbouncer due to the way we use the connection strings in our migrations. The initial pr name was a typo but has been rectified. Correct you can probably run it in session mode but its not something we have tested. What confusion is this causing in your org? In a self-hosted environment we want to limit the blast radius of things we support/have to guide people on configuring.
Author
Owner

@ardentperf commented on GitHub (Jun 11, 2025):

pgbouncer acts as a postgres server, clients simply point to the pgbouncer host/port and no connection string changes should be needed. this is whats confusing. yes it should be fine in session mode ~ many apps don't explicitly test with pgbouncer. pgbouncer is very widely used... can we revert this change and then i can provide feedback on whether we see any issues after deploying langchain with pgbouncer?

was there another user who saw problems while using pgbouncer? is there a github issue i can review and maybe help give feedback?

@ardentperf commented on GitHub (Jun 11, 2025): pgbouncer acts as a postgres server, clients simply point to the pgbouncer host/port and no connection string changes should be needed. this is whats confusing. yes it should be fine in session mode ~ many apps don't explicitly test with pgbouncer. pgbouncer is very widely used... can we revert this change and then i can provide feedback on whether we see any issues after deploying langchain with pgbouncer? was there another user who saw problems while using pgbouncer? is there a github issue i can review and maybe help give feedback?
Author
Owner

@langchain-infra commented on GitHub (Jun 11, 2025):

This is primarily more of an operational concern than a product limitation. We often get users in self-hosted who run into errors like:

asyncpg.exceptions.ProtocolViolationError: unsupported startup parameter: lock_timeout

(or for search path).

Which requires adding these to your pgbouncer config

ignore_startup_parameters = search_path,lock_timeout

Our migrations require running pgbouncer with session mode or else you run into errors:
This requires adding

pool_mode = session

While you can certainly get it working, lots of teams deploying our product aren't experienced with PG. This also means we have to be careful of adding startup parameters etc. It is another tool in our cartesian product of things we have to support in our self-hosted product. We could potentially say "not officially supported" in the documentation.

@langchain-infra commented on GitHub (Jun 11, 2025): This is primarily more of an operational concern than a product limitation. We often get users in self-hosted who run into errors like: ``` asyncpg.exceptions.ProtocolViolationError: unsupported startup parameter: lock_timeout ``` (or for search path). Which requires adding these to your pgbouncer config ``` ignore_startup_parameters = search_path,lock_timeout ``` Our migrations require running pgbouncer with session mode or else you run into errors: This requires adding ``` pool_mode = session ``` While you can certainly get it working, lots of teams deploying our product aren't experienced with PG. This also means we have to be careful of adding startup parameters etc. It is another tool in our cartesian product of things we have to support in our self-hosted product. We could potentially say "not officially supported" in the documentation.
Author
Owner

@ardentperf commented on GitHub (Jun 11, 2025):

ah-ha, thanks, that bit of detail helps a lot. yes setting the lock_timeout is a good idea for schema migrations, and kits like liquibase/flyway can bump into this too.

i would assume that langchain is setting both search_path and lock_timeout at connection time and never changing them with SET commands? (for now anyway? as far as you know?) this should technically be safe with pgbouncer and ignore_startup_parameters. i think the main thing with startup parameters is that pgbouncer will pass them through to the server but won't track them. if the clients are 100% consistent and params are static then it should be safe. (as long as the connection pool doesn't get polluted - for example with a manual pgAdmin connection using the same login+database.)

FWIW, i googled "postgres unsupported startup parameter" and four of the top five hits all pointed directly to pgbouncer. the pgbouncer documentation is decent around ignore_startup_parameters.

would you be open if i submitted a PR to change the language to this?

Support for PGBouncer and other connection poolers is unofficial and community-based only. Users have reported that it works with pool_mode = session and a suitable setting for ignore_startup_parameters (as of writing, search_path and lock_timeout need to be ignored). Care is needed to avoid polluting pgbouncer; some level of postgres expertise is advisable. We currently do not plan to add formal PGBouncer test coverage, but users are welcome to discuss and look for community support through GitHub issues.

@ardentperf commented on GitHub (Jun 11, 2025): ah-ha, thanks, that bit of detail helps a lot. yes setting the lock_timeout is a good idea for schema migrations, and kits like liquibase/flyway can bump into this too. i would assume that langchain is setting both `search_path` and `lock_timeout` at connection time and never changing them with `SET` commands? (for now anyway? as far as you know?) this should technically be safe with pgbouncer and `ignore_startup_parameters`. i think the main thing with startup parameters is that pgbouncer will pass them through to the server but won't track them. if the clients are 100% consistent and params are static then it should be safe. (as long as the connection pool doesn't get polluted - for example with a manual pgAdmin connection using the same login+database.) FWIW, i googled "postgres unsupported startup parameter" and four of the top five hits all pointed directly to pgbouncer. the pgbouncer documentation is decent around `ignore_startup_parameters`. would you be open if i submitted a PR to change the language to this? > Support for PGBouncer and other connection poolers is unofficial and community-based only. Users have reported that it works with `pool_mode` = `session` and a suitable setting for `ignore_startup_parameters` (as of writing, `search_path` and `lock_timeout` need to be ignored). Care is needed to avoid polluting pgbouncer; some level of postgres expertise is advisable. We currently do not plan to add formal PGBouncer test coverage, but users are welcome to discuss and look for community support through GitHub issues.
Author
Owner

@langchain-infra commented on GitHub (Jun 11, 2025):

@ardentperf that is great! Thank you for the discourse/understanding. Send me the pr when you get the chance and I'll take a look

@langchain-infra commented on GitHub (Jun 11, 2025): @ardentperf that is great! Thank you for the discourse/understanding. Send me the pr when you get the chance and I'll take a look
Author
Owner

@ardentperf commented on GitHub (Jun 24, 2025):

@langchain-infra the PR is linked above

@ardentperf commented on GitHub (Jun 24, 2025): @langchain-infra the PR is linked above
Author
Owner

@langchain-infra commented on GitHub (Jun 24, 2025):

Thanks, updated

@langchain-infra commented on GitHub (Jun 24, 2025): Thanks, updated
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langsmith-docs#78