Skip to content

invalid length of startup packet #313

New issue

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

By clicking “No 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? No Sign in to your account

Closed
francoricci opened this issue Jun 10, 2018 · 3 comments
Closed

invalid length of startup packet #313

francoricci opened this issue Jun 10, 2018 · 3 comments

Comments

@francoricci
Copy link

  • asyncpg version: 0.16.0
  • PostgreSQL version: 9.6.8
  • **Do you use a PostgreSQL SaaS? NO
  • Python version: 3.6.5
  • Platform: FreeBSD 11.2
  • Do you use pgbouncer?: NO
  • Did you install asyncpg with pip?: YES
  • If you built asyncpg locally, which version of Cython did you use?:
  • Can the issue be reproduced under both asyncio and
    uvloop?
    : YES

The following script :

import asyncio
import asyncpg
import uvloop

async def run():
conn = await asyncpg.connect(host='127.0.0.1', port='5432', user='root', password='pippo', database='postgres', ssl=None)
values = await conn.fetch("SELECT * FROM pg_type")
await conn.close()
asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())
loop = asyncio.get_event_loop()
loop.run_until_complete(run())

returns:

asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
and postgresql:
LOG: invalid length of startup packet

With previous asyncpg version 0.13.0 all works well

elprans added a commit that referenced this issue Jun 11, 2018
`#if FOO == BAR` is true if neither BAR, nor FOO are defined, and on
BSDs machine endianness is declared as `_BYTE_ORDER`, not
`__BYTE_ORDER`, so we would compile a big-endian variant on
little-endian machines.

Fixes #313.
elprans added a commit that referenced this issue Jun 11, 2018
`#if FOO == BAR` is true if neither BAR, nor FOO are defined, and on
BSDs machine endianness is declared as `_BYTE_ORDER`, not
`__BYTE_ORDER`, so we would compile a big-endian variant on
little-endian machines.

Fixes #313.
@francoricci
Copy link
Author

I compiled the master version and now all works well.
thanks a lot

@fpierfed
Copy link

  • asyncpg version: 0.18.2 and master
  • PostgreSQL version: 9.6.10 and 10.6
  • Do you use a PostgreSQL SaaS? NO
  • Python version: 3.6.6
  • Platform: FreeBSD 11.2
  • Do you use pgbouncer?: NO
  • Did you install asyncpg with pip?: YES (used setup.py for master)
  • If you built asyncpg locally, which version of Cython did you use?: 0.29
  • Can the issue be reproduced under both asyncio and uvloop?: YES

Sorry to reopen this issue, but I am seeing the same error with the latest released asyncpg (0.18.2) as well as today's master.

Here is the postgres log

DEBUG:  00000: forked new backend, pid=4606 socket=9
LOCATION:  BackendStartup, postmaster.c:4038
LOG:  00000: connection received: host=[local]
LOCATION:  BackendInitialize, postmaster.c:4192
LOG:  08P01: invalid length of startup packet
LOCATION:  ProcessStartupPacket, postmaster.c:1942
DEBUG:  00000: shmem_exit(0): 0 before_shmem_exit callbacks to make
LOCATION:  shmem_exit, ipc.c:226
DEBUG:  00000: shmem_exit(0): 0 on_shmem_exit callbacks to make
LOCATION:  shmem_exit, ipc.c:259
DEBUG:  00000: proc_exit(0): 1 callbacks to make
LOCATION:  proc_exit_prepare, ipc.c:188
DEBUG:  00000: exit(0)
LOCATION:  proc_exit, ipc.c:141
DEBUG:  00000: shmem_exit(-1): 0 before_shmem_exit callbacks to make
LOCATION:  shmem_exit, ipc.c:226
DEBUG:  00000: shmem_exit(-1): 0 on_shmem_exit callbacks to make
LOCATION:  shmem_exit, ipc.c:259
DEBUG:  00000: proc_exit(-1): 0 callbacks to make
LOCATION:  proc_exit_prepare, ipc.c:188
DEBUG:  00000: reaping dead processes
LOCATION:  reaper, postmaster.c:2779
DEBUG:  00000: server process (PID 4606) exited with exit code 0
LOCATION:  LogChildExit, postmaster.c:3552

@francoricci
Copy link
Author

Error start from version >= 1.18.0

elprans added a commit that referenced this issue Jan 2, 2019
This is a regression of #313, since pgproto had picked up an unfixed
version of hton.h

Fixes: #396
elprans added a commit that referenced this issue Jan 2, 2019
This is a regression of #313, since pgproto had picked up an unfixed
version of hton.h

Fixes: #396
No Sign up for free to join this conversation on GitHub. Already have an account? No Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants