[Bug]: Tabularis cannot connect to PostgreSQL via kubectl port-forward while pgAdmin works

Describe the bug

Description

Tabularis fails to connect to a PostgreSQL instance exposed locally via kubectl port-forward.
The client returns the following error:

Error: error communicating with database: failed to lookup address information: nodename nor servname provided, or not known

However, the same database connection works correctly when using pgAdmin and psql, which suggests the database itself and the port-forward are functioning correctly.

This indicates a potential issue in how Tabularis resolves or parses the connection parameters.

To Reproduce

Steps to reproduce
1. Expose PostgreSQL service locally using port-forward:
kubectl port-forward svc/postgres 5432:5432
2. Connect using pgAdmin:
Host: localhost Port: 5432 Database: postgres User: postgres
Connection succeeds.
3. Attempt the same connection in Tabularis using identical parameters.
4. Tabularis returns:
Error: error communicating with database: failed to lookup address information: nodename nor servname provided, or not known

OS Version

macOS 26.3.1

Tabularis Version

v0.9.6

Relevant Log Output

Thanks for feedback.
Are you able to debug from code?
I am afk now but I can do a check later

fix: normalize localhost to 127.0.0.1 to prevent IPv6 DNS resolution …

@getsueineko

@getsueineko i suspected is something related to localhost resolution.
But i am afk.
I sent the request to Claude Code If you want to do a check I referenced the commit in this issue if you want check.

I will check when I'll back

I'm not rustman =)

I tried to debug the connection using tcpdump while connecting Tabularis to a PostgreSQL instance exposed via kubectl port-forward.

Command used:

sudo tcpdump -i lo0 -X port 53729

Connection sequence observed:
1. TCP handshake completes successfully.
2. Client sends PostgreSQL SSLRequest:
0000 0008 04d2 162f
3. Server responds with S (SSL supported).
4. Client starts TLS handshake (ClientHello).
The packet begins with:
16 03 03
5. Inside ClientHello the SNI value appears to be 127.0.0.1.
6. Server immediately responds with a TLS alert:
15 03 03 00 02 02 46
which corresponds to:
TLS fatal alert: certificate_unknown
7. After that the server closes the TCP connection (FIN).

So the connection flow looks like:

TCP connect
→ SSLRequest
→ server returns S
→ TLS ClientHello (SNI=127.0.0.1)
→ TLS alert certificate_unknown
→ connection closed.

This suggests the failure happens during TLS negotiation rather than PostgreSQL authentication.

The instance is accessed through kubectl port-forward, so the client connects to 127.0.0.1, while the PostgreSQL server certificate is issued for the Kubernetes service hostname like postgres.default.svc.cluster.local

I will definitely check it when I will be on pc

@getsueineko

@getsueineko Can you check if #77 has been solved the issue?
It's on main branch now.

Version 0.9.7 - the same error occurs when selecting any of the four SSL modes, but now the menu for selecting databases works, meaning there is a connection, but at the same time, there isn't one.
Maybe the problem is in the http/https scheme?? I use http

Version 0.9.7 - the same error occurs when selecting any of the four SSL modes, but now the menu for selecting databases works, meaning there is a connection, but at the same time, there isn't one. Maybe the problem is in the http/https scheme?? I use http

Why HTTP or HTTPS? It's a database, not an API.
This one is working on my side:

I agree about scheme, however

None of the SSL modes is working in your case?

In pgAdmin, click on your server name, go to the Properties tab on the right, and look at Connection String.

In my case, I see: sslmode=prefer (I've not set it manually)

I've tried all the options, but to no avail. In pgdmin I see prefer mode. But in tabularis I have same error "Error: error occurred while attempting to establish a TLS connection: bad protocol version"

Cap.2026-03-15.at.16.38.08.mp4

Can you tell me how you've deployed this PostgreSQL instance?
So I can try to reproduce your setup and issue

Can you tell me how you've deployed this PostgreSQL instance? So I can try to reproduce your setup and issue

I use the https://cloudnative-pg.io/ with settings like these:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: projectname
spec:
  affinity:
    podAntiAffinityType: preferred
  backup:
    barmanObjectStore:
      destinationPath: s3://pg-projectname-backup
      endpointURL: http://rook-ceph-rgw-ceph-objectstore.rook-ceph.svc.cluster.local
      s3Credentials:
        accessKeyId:
          key: ACCESS_KEY_ID
          name: projectname-s3-wals
        region:
          key: region
          name: projectname-s3-wals
        secretAccessKey:
          key: ACCESS_SECRET_KEY
          name: projectname-s3-wals
      wal:
        compression: gzip
        maxParallel: 4
    retentionPolicy: 30d
    target: prefer-standby
  bootstrap:
    initdb:
      database: root
      encoding: UTF8
      localeCType: C
      localeCollate: C
      owner: root
      postInitSQL:
      - ALTER USER root WITH SUPERUSER;
      secret:
        name: projectname-db-root-user
  enableSuperuserAccess: false
  failoverDelay: 0
  imageName: ghcr.io/cloudnative-pg/postgresql:15.8
  instances: 3
  logLevel: debug
  maxSyncReplicas: 1
  minSyncReplicas: 1
  monitoring:
    customQueriesConfigMap:
    - key: queries
      name: cnpg-default-monitoring
    disableDefaultQueries: false
    enablePodMonitor: true
  postgresGID: 26
  postgresUID: 26
  postgresql:
    pg_hba:
      - hostssl replication replicator 10.7.23.0/24 md5
    parameters:
      archive_mode: "on"
      archive_timeout: 5min
      auto_explain.log_min_duration: 10s
      checkpoint_completion_target: "0.95"
      default_statistics_target: "100"
      effective_io_concurrency: "200"
      huge_pages: "try"
      maintenance_work_mem: 1GB
      max_connections: "300"
      max_parallel_maintenance_workers: "4"
      max_parallel_workers: "16"
      max_parallel_workers_per_gather: "4"
      max_replication_slots: "5"
      max_worker_processes: "32"
      pg_stat_statements.max: "10000"
      pg_stat_statements.track: all
      shared_buffers: 1GB
      wal_buffers: 16MB
      wal_keep_size: "1024MB"
      wal_receiver_timeout: 5s
      wal_sender_timeout: 5s
      synchronous_commit: "remote_write"
      bgwriter_lru_maxpages: "200"
      bgwriter_lru_multiplier: "4"
      bgwriter_delay: 100ms
      max_standby_streaming_delay: 300s
      track_io_timing: "on"
      track_activity_query_size: "32768"
      track_wal_io_timing: "on"
    syncReplicaElectionConstraint:
      enabled: true
      nodeLabelsAntiAffinity:
      - kubernetes.io/hostname
  primaryUpdateMethod: restart
  primaryUpdateStrategy: unsupervised
  replicationSlots:
    highAvailability:
      enabled: true
      slotPrefix: _cnpg_
    updateInterval: 30
  resources:
    limits:
      cpu: "4"
      memory: 3Gi
    requests:
      cpu: "1"
      memory: 3Gi
  smartShutdownTimeout: 180
  startDelay: 3600
  stopDelay: 1800
  storage:
    resizeInUseVolumes: true
    size: 30Gi
    storageClass: storagename
  switchoverDelay: 3600

@getsueineko

Hi @getsueineko, I have PG in k8s with CNPG as well, and is one of the reasons I submitted #246 which is now available. Have you tried it already? Perhaps this solves your problem.

Closing due to inactivity. Native Kubernetes port-forward support (#246) is now available and should cover this setup. If it still fails on the latest release, feel free to reopen.

Navigation Menu

Repository navigation

[Bug]: Tabularis cannot connect to PostgreSQL via kubectl port-forward while pgAdmin works #75

Describe the bug

To Reproduce

OS Version

Tabularis Version

Relevant Log Output

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Tabularis cannot connect to PostgreSQL via kubectl port-forward while pgAdmin works #75

Description

Describe the bug

To Reproduce

OS Version

Tabularis Version

Relevant Log Output

Activity

debba commented on Mar 7, 2026

debba commented on Mar 7, 2026

getsueineko commented on Mar 7, 2026

debba commented on Mar 7, 2026

debba commented on Mar 9, 2026

getsueineko commented on Mar 10, 2026

sycured commented on Mar 12, 2026

getsueineko commented on Mar 12, 2026

sycured commented on Mar 12, 2026

getsueineko commented on Mar 15, 2026

sycured commented on Mar 17, 2026

getsueineko commented on May 5, 2026

metalgrid commented on Jun 16, 2026

debba commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions