簡介這是PostgreSQL 18 Beta2的源碼壓縮包面向Linux平臺下的數(shù)據(jù)庫內(nèi)核研發(fā)人員、高級DBA及對開源數(shù)據(jù)庫實現(xiàn)感興趣的開發(fā)者可用于編譯安裝、源碼級調(diào)試與二次迭代。包體共2000個文件約27.79MB以1069個C源文件和885個頭文件為核心組件C文件對應(yīng)表管理、規(guī)則系統(tǒng)、數(shù)值運算、預(yù)寫日志、堆存儲、查詢規(guī)劃等關(guān)鍵模塊頭文件則提供模塊間接口與數(shù)據(jù)結(jié)構(gòu)定義另有少量TXT/MD說明文檔、Shell構(gòu)建腳本和SQL測試用例輔助理解整體編譯和驗證流程。目前已有54人下載學習。資源完整保留了PostgreSQL服務(wù)端的主要實現(xiàn)便于深入對照多版本并發(fā)控制、時間點恢復(fù)、異步復(fù)制等企業(yè)級特性來推演源碼邏輯也適合在Linux環(huán)境直接展開源碼構(gòu)建與定制從中體會數(shù)據(jù)庫內(nèi)核在事務(wù)、存儲、優(yōu)化器等方面的設(shè)計取舍是一份難得的底層學習材料。1. 拿到 postgresql-18beta2.tar.gz 之后先想清楚這三件事第一次拿到 postgresql-18beta2.tar.gz我通常先看一眼文件尾部的時間戳確認它是不是社區(qū)剛放出來的第二個測試版。這個包是 PostgreSQL 18 的源碼歸檔和官方倉庫里的源碼包內(nèi)容一致區(qū)別只是被打成了 tar.gz 方便分發(fā)。它的價值不是直接上生產(chǎn)而是把正式版發(fā)布前的最后一個窗口用起來驗證新特性、跑一遍回歸測試、把升級鏈路的坑全部踩在測試環(huán)境里。反直覺的地方在于beta2 往往比最終版更值得裝。因為大版本的功能特性在 beta1 已經(jīng)凍結(jié)beta2 主要在做修復(fù)和收口你現(xiàn)在編譯出來的東西跟個把月后的 RC 在功能面上已經(jīng)高度接近。適合讀這篇的人很明確要給 18 做技術(shù)預(yù)研的 DBA、想提前適配新版驅(qū)動和運維腳本的平臺工程師以及愿意花半小時編譯一個源碼包來換后續(xù)省事的嘗鮮派。動手前只需要想清楚三件事——裝到哪個目錄、要不要動 configure 開關(guān)、拿哪個數(shù)據(jù)目錄去初始化剩下的交給命令。2. 解壓 postgresql-18beta2.tar.gzconfigure 之前先備好依賴與編譯開關(guān)2.1 解壓 tar.gz 的正確姿勢與目錄結(jié)構(gòu)拿到包后第一件事不是解壓而是確認校驗和。官方發(fā)布頁會給 SHA256本地算一遍再動手能省掉后面排查玄學問題的時間sha256sum postgresql-18beta2.tar.gz tar -xf postgresql-18beta2.tar.gz cd postgresql-18beta2/ ls -F | sed -n 1,15ptar -xf不寫-zGNU tar 會自動識別 gzip 壓縮格式手工加-z反而容易在跨平臺時因為 tar 版本差異翻車。解壓后目錄結(jié)構(gòu)值得看一眼根目錄的configure是核心構(gòu)建腳本src/下按backend、bin、interfaces、pl分層doc/里是當前版本的 SGML 文檔源碼。這個目錄結(jié)構(gòu)對后續(xù)排錯很有用。比如編譯期間報錯你能根據(jù)報錯文件路徑快速判斷是優(yōu)化器代碼還是備份工具鏈的問題。另外注意一點官方 tar.gz 包內(nèi)部已經(jīng)帶了生成好的語法解析器所以編譯期間不需要單獨安裝 flex 和 bison只有當你從 Git 倉庫直接拉源碼時才必須準備這兩個工具。這個差異每年都有人踩看到 configure 通過卻在 make 階段報bison: not found的人十有八九是拿 Git 源碼當 tar.gz 在用。2.2 編譯工具鏈和依賴庫清單少一個 -develconfigure 就在同一步摔跤PostgreSQL 源碼編譯的依賴不算多但缺一個都過不了 configure。常見的發(fā)行版按兩套命令來準備。以 RHEL/Rocky 系為例yum install -y gcc make readline-devel zlib-devel libicu-devel perlDebian/Ubuntu 系對應(yīng)這套apt-get update apt-get install -y build-essential libreadline-dev zlib1g-dev libicu-dev perl這里的名字很容易誤導人。readline-devel和libreadline-dev是同一個東西在不同發(fā)行版里的叫法它們提供的是頭文件而readline或libreadline8只提供運行庫。很多人只裝了運行庫結(jié)果 configure 報錯時看到的信息是readline library not found第一反應(yīng)是去重裝 readline實際上缺的是開發(fā)包。依賴的作用也講清楚readline 管 psql 交互行編輯沒有它你連向上翻歷史命令都用不了zlib 影響pg_dump壓縮和 WAL 歸檔ICU 決定排序規(guī)則PostgreSQL 15 之后默認構(gòu)建就帶 ICU 支持如果不想因為排序規(guī)則不一致導致索引行為跟線上不一樣建議在編譯時顯式打開。裝完后可以快速確認頭文件就位ls /usr/include/readline/readline.h /usr/include/zlib.h pkg-config --modversion icu-uc補充一個容易被忽略的點GCC 版本不要太老。PG 18 的 beta 代碼大量使用新語法CentOS 7 自帶的 GCC 4.8.5 很可能編譯到某個文件直接報語法錯誤而且報錯位置跟真實原因離得很遠。我的做法是在編譯手工升級 GCC 到 8 以上再繼續(xù)不值得在這里浪費時間。2.3 configure 的四類開關(guān)不只有 --prefixconfigure 是源碼安裝最關(guān)鍵的一步因為它決定你后面編譯哪些模塊、鏈接哪些庫、安裝到哪里。最小可用的寫法是只給定前綴目錄但既然要驗證 beta2我建議把下面這套參數(shù)用起來./configure --prefix/opt/pgsql18 \ --with-icu --with-uuide2fs \ --with-openssl --enable-nls --enable-debug--prefix/opt/pgsql18是安裝根目錄后續(xù)所有二進制、庫、文檔都裝到這里。用獨立前綴目錄而不是默認的/usr/local是為了避免跟系統(tǒng)自帶的 PostgreSQL 版本混在一起升級和回退都干凈。--with-icu啟用 ICU 排序規(guī)則支持這個開關(guān)直接影響initdb階段能選哪些 locale--with-uuide2fs使用 Linux 自帶的 libuuid讓gen_random_uuid()和uuid-ossp擴展在編譯期就把依賴解決掉否則后面建擴展時會報找不到共享庫--with-openssl支持 SSL 加密連接生產(chǎn)環(huán)境幾乎必開--enable-nls開啟消息本地化讓服務(wù)端日志和psql提示支持中文本地化不想要這個開銷也可以去掉--enable-debug保留-g調(diào)試符號真遇到 core dump 時能多拿到一點現(xiàn)場信息代價是二進制體積變大。當 configure 跑完最后一行會顯示PostgreSQL is ready to be built.。如果中間報錯不要急著改參數(shù)重跑先看具體是哪個依賴沒過——我遇到過 90% 的 configure 失敗都能追溯到缺 -devel 包而不是參數(shù)寫錯。2.4 configure 日志怎么讀錯誤不一定出現(xiàn)在最后一行configure 的輸出有多層嵌套真正的失敗點往往藏在checking for ...中間位置。為了不盯著終端干等推薦把輸出重定向到文件里再觀察./configure --prefix/opt/pgsql18 \ --with-icu --with-uuide2fs \ --with-openssl --enable-nls --enable-debug \ /tmp/cfg18.log 21 echo exit code: $? grep -i -n error\|not found /tmp/cfg18.log | tail -20$?是 configure 進程的退出碼0 表示成功非 0 則必失敗。grep -i是為了避免大小寫干擾很多庫名在日志里首字母大寫或全大寫大小寫敏感地搜容易漏。這里有個小經(jīng)驗如果日志末尾出現(xiàn)一段checking for readline... no但系統(tǒng)里明明裝了 readline那基本可以斷定是頭文件缺失也就是 2.2 里說的-devel包沒裝。日志里也會給出 cache 文件config.cache如果改完依賴重新 configure建議先刪掉它再跑否則部分舊探測結(jié)果會被緩存導致你以為改了配置其實沒生效。3. make 與 make install把 18beta2 裝到 /opt/pgsql18 并配好運行用戶3.1 make -j 的并行度不是核數(shù)越多越好configure 通過后正式進入編譯階段。命令看起來簡單但并行度設(shè)不對會把你卡在 OOM 上make -j4如果嫌 4 太慢可以先看機器核數(shù)和內(nèi)存再決定nproc free -h make -j$(nproc)這里的反直覺點在于編譯 PostgreSQL 不是單純的高 IO 任務(wù)每個編譯單元都是大文件展開GCC 在并行編譯時內(nèi)存消耗幾乎是線性疊加的。一臺 32 核但只有 16GB 內(nèi)存的機器make -j32跑到一半可能直接觸發(fā)內(nèi)核 OOM把正在編譯的進程殺掉然后你看到的是一段完全不指向根因的Killed信息。我一般用物理內(nèi)存GB減去 2 后再取一個保守值作為并行數(shù)比如 16GB 內(nèi)存就用-j432GB 才敢上-j8。編譯需要多長時間取決于 CPU 和磁盤。較新的服務(wù)器上首次全量編譯大約 20 到 40 分鐘老機器可能超過一小時。這個時間段不用干等可以提前準備第 4 章要用的目錄和用戶。如果編譯中途失敗修復(fù)依賴后直接重跑同一條make -j4make 會跳過已經(jīng)編譯成功的部分做增量通常復(fù)編只要原來的幾分之一時間。3.2 make install 與安裝布局驗證裝完先看 pg_config編譯結(jié)束后執(zhí)行安裝。這里有一個常見的權(quán)限困惑configure 是用普通用戶跑的但--prefix/opt/pgsql18需要寫/opt所以make install要用 root 或 sudo 執(zhí)行sudo make -j4 install /opt/pgsql18/bin/pg_config --version /opt/pgsql18/bin/pg_config --bindir --sharedirmake -j4 install里再帶一次-j4是有效的它讓 install 階段的文件拷貝也能并行但多數(shù)時候 install 本身就很快帶不帶差別不大。/opt/pgsql18/bin/pg_config --version用來確認安裝的確實是 18beta2 而不是之前殘留的版本。pg_config這個工具經(jīng)常被忽略但它幾乎是所有依賴 PG 的第三方庫編譯時的鑰匙--bindir返回二進制目錄、--sharedir返回擴展 SQL 腳本目錄、--pkglibdir返回共享庫目錄。后面裝 TimescaleDB 這類擴展時configure 會直接調(diào)用pg_config尋找 PG 的安裝路徑所以環(huán)境變量里把/opt/pgsql18/bin加到 PATH 是必須的。安裝后的目錄結(jié)構(gòu)要心里有數(shù)bin/放著postgres、psql、pg_dump、pg_ctl等全部工具lib/是擴展和內(nèi)部動態(tài)庫share/存放擴展的 SQL 安裝腳本、時區(qū)數(shù)據(jù)、消息翻譯文件include/是開發(fā)頭文件。整個安裝目錄可以隨時整體刪掉重來這個特性是源碼包最大的后悔藥。3.3 創(chuàng)建運行用戶與數(shù)據(jù)目錄隔離root 只在安裝時出現(xiàn)一次PostgreSQL 的服務(wù)進程嚴禁用 root 運行這是從 initdb 階段就強制檢查的。所以安裝完成后馬上創(chuàng)建專用運行賬號并把數(shù)據(jù)目錄的所有權(quán)切過去sudo useradd -M -s /bin/bash pgsql sudo mkdir -p /var/lib/pgsql/18/{data,log} sudo chown -R pgsql:pgsql /var/lib/pgsql/18 sudo chmod 700 /var/lib/pgsql/18/data-M表示不創(chuàng)建 home 目錄對專門跑數(shù)據(jù)庫的用戶來說 home 目錄用途不大省得系統(tǒng)再生成一個默認目錄。data目錄權(quán)限必須設(shè)成 700PostgreSQL 啟動時會主動檢查目錄權(quán)限如果是 755 它會直接拒絕啟動因為數(shù)據(jù)目錄里的文件包含敏感信息任何其他系統(tǒng)用戶都不應(yīng)該能進入。目錄規(guī)劃這里多說兩句。我習慣把數(shù)據(jù)、日志、備份三個目錄分開/var/lib/pgsql/18/data存實例數(shù)據(jù)/var/lib/pgsql/18/log存pg_ctl指定的日志備份獨立放/backup/pg18。這樣最直接的好處是清日志、清備份、做盤容量規(guī)劃都互不干擾磁盤快滿時不用在一堆文件里找誰是大頭。3.4 環(huán)境變量PATH 要加PGDATA 我勸你別加切到 pgsql 用戶后需要把 PG 的 bin 目錄加進 PATHecho export PATH/opt/pgsql18/bin:$PATH /home/pgsql/.bashrc這里不要寫全局/etc/profile只寫到 pgsql 用戶自己的 bashrc 就行避免影響系統(tǒng)上其他賬號的環(huán)境。還有個細節(jié)很多教程讓你也導出PGDATA我建議不要。PGDATA一旦全局生效你執(zhí)行initdb、pg_ctl時如果忘記寫-D參數(shù)它會靜默使用這個變量指向的目錄。在同時維護 17 和 18 兩個實例的過渡期這樣誤操作的代價非常高。每次命令顯式寫-D雖然啰嗦但能避免你啟動錯實例還渾然不知。另外如果安裝路徑是/opt/pgsql18這種非標準位置postgres進程在加載libicu等系統(tǒng)庫時一般沒問題但如果把 PostgreSQL 裝到/usr/local/pgsql外的自定義位置且遇到error while loading shared libraries才需要補LD_LIBRARY_PATH。沒遇到這個錯就不用加這個變量加多了反而會干擾其他軟件庫加載。4. initdb 與 pg_ctl初始化數(shù)據(jù)目錄、拉起實例并跑通第一個查詢4.1 initdb 參數(shù)怎么設(shè)編碼、locale、密碼、checksum 一次定好編譯完成后用 pgsql 用戶初始化數(shù)據(jù)目錄。這一步的參數(shù)會固化到postgresql.conf里后期改起來成本比一步到位高得多sudo -u pgsql /opt/pgsql18/bin/initdb \ -D /var/lib/pgsql/18/data \ -U postgres -E UTF8 \ --localeen_US.UTF-8 -W -k-D指向數(shù)據(jù)目錄目錄可以不存在initdb 會自動創(chuàng)建-U postgres指定超級用戶名不要用默認值默認會取當前系統(tǒng)用戶名如果你用 pgsql 賬號執(zhí)行超級用戶會變成 pgsql后面不少自動化腳本會默認連 postgres容易踩兼容坑-E UTF8指定數(shù)據(jù)庫默認編碼除非你有特殊兼容需求否則 UTF8 是唯一合理選擇--localeen_US.UTF-8決定排序規(guī)則要注意系統(tǒng)里必須已經(jīng)生成了這個 locale可以用locale -a確認沒有的話用--localeC.UTF-8或--localeC兜底C locale 排序快但不太符合自然語言習慣。-W會交互式要求你設(shè)置超級用戶密碼這一步不要跳過也別在命令里直接寫明文密碼以后改密碼很簡單但初始密碼留在 shell history 里很難清理。-k是--data-checksums的簡寫開啟數(shù)據(jù)塊校驗和。PG18 里默認還不開但我強烈建議打開它可以幫你提前發(fā)現(xiàn)磁盤靜默損壞代價是大約 0.5% 到 1% 的性能損耗。在 beta 版驗證階段打開能盡早暴露存儲層問題比上了生產(chǎn)再發(fā)現(xiàn)某個數(shù)據(jù)頁壞了再想辦法要有退路得多。4.2 pg_ctl 啟動日志文件先行狀態(tài)靠它確認初始化成功后啟動實例。第一次啟動必須把日志文件準備好否則 pg_ctl 會直接報錯退出sudo -u pgsql /opt/pgsql18/bin/pg_ctl \ -D /var/lib/pgsql/18/data \ -l /var/lib/pgsql/18/log/pg.log \ start-l指定日志文件路徑。這個文件不會自動創(chuàng)建但它所在的目錄必須存在且 pgsql 用戶有寫權(quán)限。如果在第 3 章按/var/lib/pgsql/18/log規(guī)劃過這一步就不會出問題。我見過有人在/tmp下放日志結(jié)果重啟后日志丟了排障時一臉懵。啟動成功的判斷標準不是 pg_ctl 打印了一串字而是pg_ctl status返回 runningsudo -u pgsql /opt/pgsql18/bin/pg_ctl \ -D /var/lib/pgsql/18/data status如果啟動失敗第一件事永遠是看日志尾部而不是重試sudo -u pgsql tail -n 40 /var/lib/pgsql/18/log/pg.log日志里最常見的啟動失敗原因是數(shù)據(jù)目錄權(quán)限不對或者某個配置參數(shù)值非法錯誤信息通常在前幾行就寫清楚了。這里提醒一句不要用一個 sudo 命令把日志 tail 出來就完事注意看時間戳確認那幾行是剛才啟動時新寫的而不是昨天遺留的舊錯誤。4.3 連接配置先搞清楚現(xiàn)在能連誰、怎么連剛初始化完的實例默認只監(jiān)聽本地 Unix socketlisten_addresses是localhost。用 pgsql 系統(tǒng)賬號直連本地 socket 不需要密碼這是 PG 的默認信任策略sudo -u pgsql psql -d postgres進入 psql 后先確認幾個關(guān)鍵參數(shù)SHOW unix_socket_directories; SHOW listen_addresses; SHOW port; SELECT version();unix_socket_directories默認是/tmp所以psql不帶-h時就能連上。listen_addresses默認是localhost意味著本機 TCP 可以連局域網(wǎng)和公網(wǎng)都不行這個默認值對測試環(huán)境來說基本夠用。如果要讓別的機器訪問用ALTER SYSTEM修改是比直接編輯 postgresql.conf 更干凈的方式因為ALTER SYSTEM只改postgresql.auto.conf不動主配置將來對比改動更容易ALTER SYSTEM SET listen_addresses 127.0.0.1; SELECT pg_reload_conf();ALTER SYSTEM寫進的參數(shù)在 reload 后生效不需要重啟。如果本機測試listen_addresses保持localhost即可改它反而多暴露一個端口給外部。4.4 把默認 trust 改成密碼認證beta 測試也別裸奔默認的 pg_hba.conf 對本地連接是trust也就是任何能登錄 pgsql 系統(tǒng)賬號的人都可以免密成為超級用戶。測試環(huán)境也建議改成scram-sha-256這一步能讓后續(xù)所有連接行為跟生產(chǎn)對齊sudo -u pgsql sed -i \ -e s/^local all all trust/local all all scram-sha-256/ \ -e s/^host all all 127.0.0.1\/32 trust/host all all 127.0.0.1\/32 scram-sha-256/ \ /var/lib/pgsql/18/data/pg_hba.conf改完配置文件后要 reloadsudo -u pgsql /opt/pgsql18/bin/pg_ctl \ -D /var/lib/pgsql/18/data reload此時用 TCP 連接就必須要密碼了順便驗證一下超管密碼是否設(shè)置成功PGPASSWORD密碼 psql -h 127.0.0.1 -U postgres -d postgres這一步如果報password authentication failed通常不是密碼錯了而是 4.1 里那個-W你沒執(zhí)行超級用戶密碼是空的認信用scram-sha-256又能通過形成了矛盾狀態(tài)。解決方式是先用本地 socket 連進去ALTER USER postgres PASSWORD 新密碼;再回來用 TCP 連。4.5 建一個應(yīng)用庫做冒煙測試beta2 能不能用來跑業(yè)務(wù)邏輯連接驗證通過后建一個應(yīng)用庫跑一圈基本操作確認編碼、權(quán)限、查詢鏈路都沒問題CREATE USER app WITH PASSWORD app_pass_123; CREATE DATABASE appdb OWNER app ENCODING UTF8; \q然后從應(yīng)用賬號視角連一次PGPASSWORDapp_pass_123 psql -h 127.0.0.1 -U app -d appdb在 appdb 里執(zhí)行CREATE TABLE t1 (id int primary key, ts timestamptz default now()); INSERT INTO t1 (id) VALUES (1), (2), (3); SELECT count(*), max(ts) FROM t1;這段冒煙覆蓋了建庫、授權(quán)、建表、寫入、聚合查詢幾條最基本路徑。PG 18 的 backend 在 beta2 階段不會再有大的行為變更如果在這里出現(xiàn)崩潰、死鎖、或者invalid memory alloc request size之類的報錯值得記下完整堆棧反饋給社區(qū)。多數(shù)情況下這套流程跑下來不會有問題但這一輪驗證跑完你對這個包是否可信就有了自己的判斷不再依賴別人的宣傳口徑。5. 源碼安裝避坑configure、initdb、升級兼容的 5 條真實踩坑5.1 configure 卡在 readline library not found現(xiàn)象./configure跑了很久最后報錯checking for readline... no或readline library not found退出碼非 0。原因系統(tǒng)里裝了 readline 運行庫但沒裝readline-devel。configure 檢查的是頭文件不是動態(tài)庫運行庫本身幫不上忙。這類問題在 CentOS/RHEL 系上尤其常見默認最小化安裝往往不帶開發(fā)包。解決不要慌裝完開發(fā)包重跑 configure 即可。RHEL 系執(zhí)行yum install -y readline-develDebian 系執(zhí)行apt-get install -y libreadline-dev裝完后再跑一次通常后面還有 zlib 和 ICU 兩個類似的坑干脆把 2.2 節(jié)里的依賴一次裝齊省得 configure 每跑一次報一個新錯。5.2 編譯到一半被 Killed日志里沒有任何錯誤現(xiàn)象make -j$(nproc)跑了幾分鐘后終端出現(xiàn)一行Killed或者編譯進程靜默消失重跑又從某個文件開始繼續(xù)反復(fù)推進不了。原因并行度過高導致內(nèi)存耗盡內(nèi)核 OOM 把編譯進程殺了。32 核機器只配 16GB 內(nèi)存時尤其常見GCC 對每個翻譯單元的內(nèi)存占用可能到 1GB 以上翻倍疊加后瞬間觸頂。解決換小并行度重編make -j4是低配機器的安全牌。也可以用make -j4先編完核心 backend再對剩余模塊用稍高并行度補編。重點是別反復(fù)用高并行度重試那不是運氣問題是資源邊界問題。5.3 initdb 報錯cannot be run as root現(xiàn)象用 root 執(zhí)行/opt/pgsql18/bin/initdb立刻報FATAL: cannot be run as root。原因PostgreSQL 從安全設(shè)計上禁止 root 初始化數(shù)據(jù)目錄。root 啟動 postgres 會讓文件權(quán)限模型失去意義任何被數(shù)據(jù)庫讀取的文件只要落在 root 權(quán)限范圍內(nèi)風險都會被放大社區(qū)直接在 initdb 里硬性攔截。解決切換用戶再執(zhí)行。sudo -u pgsql /opt/pgsql18/bin/initdb ...前提是數(shù)據(jù)目錄的屬主已經(jīng)是 pgsql。如果你用 root 在/var/lib/pgsql/18/data下創(chuàng)建過目錄需要先chown -R pgsql:pgsql再切換否則 initdb 會繼續(xù)報權(quán)限錯誤。5.4 pg_ctl start 提示 could not start server日志里是 Permission denied現(xiàn)象pg_ctl start返回失敗尾部日志只有一行Permission denied沒有更多的上下文。原因數(shù)據(jù)目錄權(quán)限不對。最常見的是用 root 執(zhí)行過mkdir或者chmod 755 data導致 pgsql 用戶無法在數(shù)據(jù)目錄里創(chuàng)建postmaster.pid和臨時文件。PostgreSQL 對數(shù)據(jù)目錄權(quán)限非常嚴格755 都不行必須是 700。解決chown -R pgsql:pgsql /var/lib/pgsql/18/data然后chmod 700 /var/lib/pgsql/18/data。另外順便檢查有沒有殘留的postmaster.pid——如果之前異常關(guān)機留下這個文件且文件里的 PID 已經(jīng)不存在PostgreSQL 會因為檢測到 stale pid 而拒絕啟動。先ps -ef | grep postgres確認沒有活著的進程再刪掉這個 pid 文件重新啟動。5.5 拿舊版本數(shù)據(jù)目錄直接啟動 PG 18beta2報 database files are incompatible現(xiàn)象把 PG 13 或 PG 17 的數(shù)據(jù)目錄-D指給 18beta2 的 pg_ctl啟動直接失敗日志里出現(xiàn)FATAL: database files are incompatible with server。原因PG 的主版本數(shù)據(jù)目錄格式不向下兼容beta2 連兼容 PG 17 數(shù)據(jù)目錄的能力都沒有。這個錯誤發(fā)生在啟動早期所以你不會看到任何日志細節(jié)因為它根本沒走到讀取數(shù)據(jù)那一步。解決beta 階段不要做任何“原地升級”的嘗試。驗證升級路徑要用邏輯遷移先從舊庫pg_dump出來再往 18beta2 實例里pg_restorepg_dump -h 舊庫地址 -U postgres -Fc 舊庫名 beta18_before.dump PGPASSWORDapp_pass_123 psql -h 127.0.0.1 -U app -d appdb -c DROP SCHEMA public CASCADE; CREATE SCHEMA public; pg_restore -h 127.0.0.1 -U app -d appdb --no-owner beta18_before.dump--no-owner是必須的因為 dump 文件里記錄的是舊庫的屬主和權(quán)限恢復(fù)到新環(huán)境時如果用戶不一致會報一堆角色不存在。這個流程跑通之后等 PG 18 正式版出來再評估pg_upgrade這類原地升級工具beta 階段不用惦記它。6. 回歸測試與升級演練判斷 18beta2 值不值得投入的兩種驗證6.1 make check讓編譯器替你回答“這個包能用嗎”在所有手工冒煙之外PostgreSQL 自帶一套完整回歸測試這是判斷源碼包是否健康的最快路徑make -j4 check這個命令會在源碼目錄的臨時子目錄里創(chuàng)建一個獨立測試實例運行幾千條 SQL 和工具測試后自動清理不會污染你現(xiàn)在正在跑的 5432 實例。跑完看末尾的匯總?cè)绻霈F(xiàn)All tests passed或者只有個別已知失敗項說明當前環(huán)境和編譯器組合是可用的如果出現(xiàn)大段失敗通常不是代碼壞了而是測試環(huán)境里某些 locale 或擴展依賴沒配對比如 ICU locale 缺失會導致一批排序規(guī)則相關(guān)用例失敗。注意make check默認會占用物理端口 65432 附近的地址如果被占用顯式指定端口再跑make -j4 check PORT65433這套測試在 beta2 階段跑一遍很有價值。它相當于社區(qū)幫你打包好的冒煙清單覆蓋了解析器、執(zhí)行器、事務(wù)、備份工具等幾乎所有子系統(tǒng)。我通常拿它作為“這個包能不能信”的硬指標比自己寫幾十條 SQL 的覆蓋面大得多。6.2 升級演練記錄三段時間正式版來時你就有底beta2 階段做升級演練成本很低收益卻在正式版發(fā)布那天兌現(xiàn)。我給自己的要求是每次 beta 都要完整記錄三段時間pg_dump耗時、pg_restore耗時、業(yè)務(wù)查詢冒煙耗時。格式很簡單環(huán)節(jié)關(guān)鍵命令關(guān)注點備份pg_dump -Fc olddb beta18.dump有沒有權(quán)限報錯、耗時波動恢復(fù)pg_restore -d appdb --no-owner beta18.dump對象是否完整、有無類型轉(zhuǎn)換告警驗證跑一遍業(yè)務(wù)核心查詢排序規(guī)則、索引是否行為變化如果 dump 出來的文件里包含擴展對象比如postgis或uuid-ossprestore 之前要確認新環(huán)境已經(jīng)編譯安裝了對應(yīng)擴展。beta2 階段最容易翻車的是自制類型和函數(shù)那些依賴 PG 內(nèi)部行為變化的對象dump 不一定報錯但 restore 時可能語義已經(jīng)不一樣。所以恢復(fù)后別只看表數(shù)量對得上要挑幾條業(yè)務(wù)查詢實際跑一遍。我養(yǎng)成的習慣是每個大版本 beta1 出來先編譯一次探路beta2 換 tar.gz 重編一遍并完整跑回歸等 RC 出現(xiàn)時升級計劃基本就是把驗證過的流程原樣復(fù)制而不是臨時現(xiàn)學。beta2 階段花掉的這一個小時換來的是正式版落地當天的從容。希望幫到你。本文還有配套的精品資源點擊獲取