f relation "xxxxxx" page 910848 is uninitialized --- fixing ~ 迪貝之家

relation "xxxxxx" page 910848 is uninitialized --- fixing

 

在某個資料庫裡頭
手動vacuum某個表
常發生這個問題
2020-09-21 10:45:33 CST [6755] : [150279-1] WARNING: 01000: relation "test" page 910848 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150281-1] WARNING: 01000: relation "test" page 910849 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150283-1] WARNING: 01000: relation "test" page 910850 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150285-1] WARNING: 01000: relation "test" page 910851 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150287-1] WARNING: 01000: relation "test" page 910852 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150289-1] WARNING: 01000: relation "test" page 910853 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150291-1] WARNING: 01000: relation "test" page 910854 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150293-1] WARNING: 01000: relation "test" page 910855 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150295-1] WARNING: 01000: relation "test" page 910856 is uninitialized --- fixing
2020-09-21 10:45:33 CST [6755] : [150297-1] WARNING: 01000: relation "test" page 910857 is uninitialized --- fixing
之前一直沒時間找root cause
今天翻找了一下google
大概都是bulk insert 所造成的空間配置問題
之前一直沒時間找root cause
今天翻找了一下google
大概都是bulk insert 所造成的空間配置問題
可能的root cause有兩個
原因 1 :
These could be pages that were allocated
to put new tuples into, but the crash
happened before the inserting transaction
committed
原因 2 :
edb loader direct load 會先要求配置額外的空間
奇怪~~ 不曉得有沒有指令讓dba執行
來先把空間配出去
我管postgres這麼久了
好像還沒看到這個指令
對照了系統記錄
我原本是找看看有沒有abort
或者err字串的
結果都沒有
靠~~~
後來直接拿表格名稱去找
mmmmm................
真是edb loader所造成的
EDB*Loader
應該是我前公司的同仁
好多年前在這邊做的專案
把edb loader用java包起來執行
沒有解決之道
就是vacuum時
讓它跑完
把沒真正去要到的空間
去給要出來