Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selecting schema not worked with pgbouncer #346

Open
skyline-gleb opened this issue Apr 8, 2020 · 1 comment
Open

Selecting schema not worked with pgbouncer #346

skyline-gleb opened this issue Apr 8, 2020 · 1 comment
Labels
question Further information is requested

Comments

@skyline-gleb
Copy link

Describe the bug
Get error from asyncpg when set custom schema in connection credentials:
asyncpg.exceptions.ProtocolViolationError: unsupported startup parameter: search_path

To Reproduce
CREATE SCHEMA IF NOT EXISTS notpublic

await Tortoise.init(
    {
        "connections": {
            __name__: {
                "engine": "tortoise.backends.asyncpg",
                "credentials": {
                    **credentials,
                    "schema": "notpublic"
                }
            }
        },
        "apps": {"models": {"models": [__name__], "default_connection": __name__}},
    },
)

Expected behavior
Successfully init

Additional context
Support schema added in #172 and changed in #229

@grigi
Copy link
Member

grigi commented Apr 9, 2020

Seems that asyncpg + pgbouncer doesn't work well together unless using pool_mode=session as per MagicStack/asyncpg#339

It seems the issue is that asyncpg sets up remote state for performance, and pgbouncer is stateless. This is an issue because to do safe parametrised queries postgres requires a two-step instruction (prepare + call) and asyncpg assumes that this is available.

I see there is a suggestion to make pgbouncer work a bit better over here: MagicStack/asyncpg#348 (comment)

If the problem goes away if you set the pool_mode, then it is very likely the issue is what is descrivbed there, and we can implement a work-around so it at least works.

@grigi grigi added the question Further information is requested label Apr 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants