Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Silent port conflict goes undetected

未關閉
  • 哪裡不對？
#798 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
28/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
docker, postgresql
領域
databases, networking

研究方向

Start by reproducing the Docker and Postgres.app setup in the issue, then inspect the source references to SO_REUSEPORT and SO_REUSEADDR and compare the context from #676. Done means a conflicting listener is detected and reported reliably without allowing traffic to reach different clusters unexpectedly.

由索引模型根據 Issue 內容生成。

描述

I ran into a confusing scenario where I think Postgres.app should have reported "Port in use" and failed to start, but instead managed to bind and steal traffic from a process that was already listening on that port.

I have a Docker container running PostGIS and exposing container port 5432 on host port 5432. I was able to open a psql shell on port 5432, but was confused because the database didn't have the right data. Eventually I figured out that Postgres.app was also listening on port 5432:

$ sudo lsof -i :5432
COMMAND     PID     USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
com.docke  1029 wchargin  128u  IPv6 0x97e222976b6cf6c5      0t0  TCP *:postgresql (LISTEN)
postgres  45709 wchargin    7u  IPv6 0x91b1855dc1c99cac      0t0  TCP localhost:postgresql (LISTEN)
postgres  45709 wchargin    8u  IPv4 0xa012493f18604ea9      0t0  TCP localhost:postgresql (LISTEN)

$ ps -p 45709 -o comm
COMM
/Applications/Postgres.app/Contents/Versions/16/bin/postgres

I searched the source for SO_REUSEPORT / SO_REUSEADDR and found the comment leading to #676. I'm glad that that issue is resolved, but it seems like this issue is an unfortunate consequence of the fix.

I do think that it may be somewhat confusing to use this socket option, since it subverts the application that if an application is listening on a port then it will be able to receive packets sent to that port. Notably, this confusion only occurs because my Docker container is listening on all interfaces. If I expose 127.0.0.1:5432:5432 instead of just 5432:5432, then Postgres.app properly reports "Port in use" or the Docker container fails with "Ports are not available". So it feels a bit clumsy and unpredictable that Postgres.app behaves this way.

Might there be a different way of solving the original issue that doesn't cause this side-effect?

Steps to reproduce
  1. Make sure that Postgres.app is stopped.
  2. Run docker run --rm -e POSTGRES_PASSWORD=password -p 5432:5432 -it postgres, and leave that running in its own terminal.
  3. Run psql -h localhost -p 5432 -U postgres, and execute (say) CREATE TABLE tab(), SELECT count(1) FROM tab.
  4. Start Postgres.app. Note that it moves to the "Running" state without any error.
  5. Run psql -h localhost -p 5432 -U postgres again. Note that SELECT count(1) FROM tab now fails: no such relation.

If you have the psql shells from (3) and (5) open at the same time, you can note that their \conninfos report identical results:

You are connected to database "postgres" as user "postgres" on host "localhost" (address "::1") at port "5432".

…yet they are actually talking to different clusters!

(Then you can Ctrl-C in the terminal from step 2, which will destroy the container.)

主要語言
Makefile
星號
7.8k
分支
404
平均合併
7 小時 28 分鐘
30 天內合併 PR
4

環境準備

我們還沒有檢查這個專案的環境設定檔。先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

PostgresApp/PostgresApp 的其他 Issue

查看 PostgresApp/PostgresApp 的全部 Issue

相似的 Issue

更多 Databases Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。