osm2pgsql-replication not working with conninfo string

[rustprooflabs]

What version of osm2pgsql are you using?

2022-02-19 09:36:19  osm2pgsql version 1.6.0 (1.6.0)
Build: RelWithDebInfo
Compiled using the following library versions:
Libosmium 2.17.3
Proj [API 4] Rel. 7.2.1, January 1st, 2021
Lua 5.2.4

What operating system and PostgreSQL/PostGIS version are you using?

Uses PostGIS Docker image as base, defined by Dockerfile, available via DockerHub.

┌─────────────────────────────────────────────────────────────────────────────────────┬───────────────────────────────────────┐
│                                       version                                       │            postgis_version            │
╞═════════════════════════════════════════════════════════════════════════════════════╪═══════════════════════════════════════╡
│ PostgreSQL 14.0 (Debian 14.0-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (…│ 3.1 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 │
│…Debian 10.2.1-6) 10.2.1 20210110, 64-bit                                            │                                       │
└─────────────────────────────────────────────────────────────────────────────────────┴───────────────────────────────────────┘

Tell us something about your system

Docker container running on local machine with 12 CPU, 64 GB RAM and SSD drives.

What did you do exactly?

Attempting to update my project to include use of osm2pgsql-replication. The project already uses connection strings in the format postgresql://postgres@localhost/pgosm. I have gone through a couple rounds of local testing osm2pgsql-replication (not in Docker) with success, my rough documentation of what I have done already is here. The problem reported here was encountered as I am working on adding my prior successful testing into the Docker-based process.

Using osm2pgsql-replication init with a single connection string results in a psycopg2 error attempting to connect. In this case the command is ran as the root user so it reports the root user does not exist. This is a clear indication the conninfo string is not parsed, otherwise the postgres role would be used for the connection.

root@965797fa7760:/app# osm2pgsql-replication init -d postgresql://postgres@localhost/pgosm  --osm-file /app/output/district-of-columbia-latest.osm.pbf 
Traceback (most recent call last):
  File "/usr/local/bin/osm2pgsql-replication", line 531, in <module>
    sys.exit(main())
  File "/usr/local/bin/osm2pgsql-replication", line 523, in main
    conn = connect(args)
  File "/usr/local/bin/osm2pgsql-replication", line 78, in connect
    return psycopg.connect(dbname=args.database, user=args.username,
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 127, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "root" does not exist

What did you expect to happen?

I expect the above to work and return the same successful output received when I split the conn string apart.

root@965797fa7760:/app# osm2pgsql-replication init -d pgosm -U postgres -H localhost  --osm-file /app/output/district-of-columbia-latest.osm.pbf 
2022-02-19 09:53:37 [INFO]: Initialised updates for service 'http://download.geofabrik.de/north-america/us/district-of-columbia-updates'.
2022-02-19 09:53:37 [INFO]: Starting at sequence 3251 (2022-02-18 21:21:54+00:00).

I checked osm2pgsql-replication --init help output which states the conninfo string format should be supported.

  -d DB, --database DB  Name of PostgreSQL database to connect to or conninfo string

Based on the help output this appears it should work. This format already works with osm2pgsql itself so would be handy to support here too.

What did you do to try analyzing the problem?

I verified my conn string was valid, tried a number of variations of the conn string format to make sure it wasn't just an edge case misunderstanding, and I triple checked the help output that clearly states that a conninfo string should be supported. I verified my connection string format against other resources to be sure (again) that my format wasn't invalid or unusual.