Why pg_dump/psql throws "FATAL: no PostgreSQL user name specified in startup packet"?

Question

I am trying to run pg_dump (or even psql) over our postgresql server v13, with binaries from v13 and v16. Both don't work for me, but do work for my colleagues that are not on Mac, not sure if it's related to that.

When I try to run:

pg_dump -U grails --verbose --host=<host> --port=<port> --format=plain <db_name> > <target_file>

or even simple:

psql -U grails --host=.. --port=..

I get the following:

pg_dump: error: connection to server at "...", port ... failed: FATAL:  no PostgreSQL user name specified in startup packet
connection to server at "...", port ... failed: FATAL:  no PostgreSQL user name specified in startup packet
pg_dump(71055,0x1db08dec0) malloc: *** error for object 0x92: pointer being freed was not allocated
pg_dump(71055,0x1db08dec0) malloc: *** set a breakpoint in malloc_error_break to debug
[1]    71055 abort      pg_dump --verbose --host=... --port=... -U grails --format=plain  

The user name is clearly specified as parameter and my colleagues have no problem. The malloc errors are weird too. What might be happening?

Impromptu

That looks to me like some kind of corruption of the executable file or a library it uses. What if you try to connect with psql (rather than pg_dump) using the same connection parameters? Can you reproduce the problem on other Macs? What if you change the username to something else? I would expect it to fail, but does it fail with the same error or a different one? – Righthander

psql failed as well with the same error. Interesting. It does not fail though when connecting to my local db. Even just psql with host and port (and username) throws it when connecting to that server. If I am running on M1Pro and the server is running on a different architecture, that shouldn't be an issue, right? – Impromptu

I might try another mac a bit later to check – Impromptu

I just upgraded to Sonoma 14.1.1 and started having the same problem, my postgres is v15. Re-installing postgres with brew seems to have no effect, brew doctor doesn't think there is an issue. Colleagues who haven't upgraded yet don't seem to have this problem. – Kobarid

Answer 1

This issue (which I also faced) seems to be caused by an incompatibility/bug between Postgres and openssl version 3.2.0.

Homebrew's Postgreses now are compatible with openssl 3.2, please run brew upgrade postgresql@<YOUR POSTGRES VERSION> or brew upgrade libpq to get the fixed version here for homebrew users

(before Nov 28, 2023: Downgrading to openssl version 3.1.4 (as documented here for homebrew users) worked for me as a workaround.)

Dehydrogenase

For information: The brew postgres package has been fixed, a brew upgrade should fix the issue (see github.com/Homebrew/homebrew-core/issues/…). – Ralli

brew upgrade libpq works for me – Cancellation

Answer 2

Seems like the problem is with the brew version of Postgres. I tried installing Postgres with their installer from the official website and I am not running into the issues that I have when using binaries I fetched from homebrew.

Impromptu

It's probably some linked lib rather than postgres itself, but that's a useful workaround for the time being +1 – Kobarid

I also fixed it by brew installing a newer version of postgres brew install postgres@14 even though the remote database is pg 13.10. The failing version from brew was 13.13 – Eurydice