Must Story

ในที่สุดก็ค้นหาคำตอบจนได้ว่าทำไม PostgreSQL 8.0.3 ที่คอมไพล์เองบนเครื่องที่เอาไว้ทำเป็นมิเรอร์ถึงไม่สนับสนุนเรื่อง multibyte ก็เป็นเรื่องที่คาใจมาตลอดระยะเวลาหลายสัปดาห์ ว่าทำไม ....

---

ขอย้อนกลับไปนิดนึงว่าปัญหาที่เกิดขึ้นเป็นอย่างไร

postgres@phoenix:/etc/postgresql/8.1/main$ psql reportdb_v3
Welcome to psql 8.1.0, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

reportdb_v3=# select item_common_name From b_item where LOWER(item_common_nam e) LIKE '%cpm%';
        item_common_name
---------------------------------
 CPM  .-inj  ( 10 mg./ml. ) *
 CPM  .-tab  ( 4 mg. )*
 CPM  .-Syr  (2mg./5ml.) - 60ml.
 CPM hand
 CPM Elbow
 CPM
(6 rows)

reportdb_v3=# select item_common_name From b_item where UPPER(item_common_nam e) LIKE '%cpm%';
ERROR:  invalid multibyte character for locale
reportdb_v3=#

และเมื่อลองดูตัวแปรที่เกี่ยวข้องก็ได้ตามนี้

postgres@phoenix:/etc/postgresql/8.1/main$ cat /etc/environment
LANGUAGE="en_TH:en_US:en_GB:en"

LANG=en_US.UTF-8

---

ไปค้นดูใน กูเกิล ด้วย keyword error+multibyte+locale site:postgresql.org ก็พบว่ามีคนเคยเจอเหมือนเรา ที่นี่ วิธีการแก้ปัญหาของเค้าคือ

1. ก่อนทำการคอมไพล์ Postgres ให้ export LANG=en_US.UTF-8 ซะก่อน แล้วค่อยทำการ ./configure ; make ;make install ไปตามลำดับ


2. ต่อเมื่อจะ initialize database ให้เพิ่ม option --locale=C ไปด้วย
   For Example
   

   postgres@mirror:$/usr/local/pgsql/bin/initdb -E UNICODE --locale=C -D /usr/local/pgsql/data

เมื่อเราทำการทดสอบดูก็ได้ผลตามนี้

เทสต์แล้วครับ บนเครื่องที่ใช้ทำงานจริง work work work ดูการ select ซะก่อน
postgres@mirror:~/tmp$ /usr/local/pgsql/bin/psql v3_repl_db
Welcome to psql 8.0.3, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

v3_repl_db=# select item_common_name from b_item where UPPER(item_common_name) like '%cpm%';
item_common_name
------------------
(0 rows)

v3_repl_db=# select item_common_name from b_item where LOWER(item_common_name) like '%cpm%';
item_common_name
---------------------------------
CPM .-inj ( 10 mg./ml. ) *
CPM .-tab ( 4 mg. )*
CPM .-Syr (2mg./5ml.) - 60ml.
CPM hand
CPM Elbow
CPM
(6 rows)

v3_repl_db=# 

จริงๆ ผมก็พึ่งนึกได้ว่าตอนที่ลง postgres จากแพกเกจของเดเบียนน่ะ ก่อนที่เค้าจะ initdb น่ะเค้าก็ถามเหมือนกันว่าจะใช้ locale เป็น C หรือว่า en_US ไอ้เราความที่เคยตัวซะชินก็ Enter ผ่าน (Enter ผ่านแล้วมันไม่มี error เรื่องนี้) เอ้อก็ต้องขอโทษขอโพยด้วยที่ไปนึกเหมาเอาว่าเกิดจากเดเบียน แฮ่ แฮ่ กว่าจะค้นหาปัญหาได้ก็ผ่านไปเดือนกว่าๆ ถ้าเกิดอะไรขึ้นกะเซอร์เวอร์ที่ให้บริการจริง ป่านนี้คงเอาหน้าไปไว้ที่ไหนไม่ได้แล้วล่ะ คิดๆอยู่เหมือนกันว่าจะเอาปัญหาไปถามที่ LTN ไหนก็เล่าแล้ว เล่าให้ฟังเลยดีกว่าว่า ตอนที่ไปงาน TMI 2005 ปีนี้คณะแพทยศาสตร์ มหาวิทยาลัยเชียงใหม่รับเป็นแม่งาน ก็ได้เจอกับ คุณ ott (ภัทระ เกียรติเสวี) ด้วย ขออนุญาตพาดพิงถึงหน่อย ในฐานะที่ติดตามงานของแกมานานตั้งแต่ทำ Linux-SIS แล้ว วันนั้นก็เข้าไปนั่งฟังคุณ ott คุยเรื่องเกี่ยวกับ Linux และการนำไปใช้งาน หลังจากจบ session แล้วผมก็ได้มีโอกาสได้พูดคุยแล้วก็เล่าให้ฟังถึงปัญหาที่ผมเจอเข้าจริง คุณ ott ก็อุตสาห์ถามย้ำแล้วนะ ว่าเซต locale แล้วหรือยัง ไอ้เราก็ยังไม่ค่อยเข้าใจ (บ้านน๊อก บ้านนอก) กลับมาก็พยายามมาค้นดู ก็เลยเจอคำตอบจังเบ้อเร่อ ก็คุยกันนานพอสมควร ทราบว่าตอนนี้กลับมาอยู่เมืองไทยแล้ว ทำธุรกิจเปิดบริษัท metamedia ร่วมกับ คุณพูลลาภ ก็ขออำนวยอวยพรให้กิจการก้าวหน้าด้วยดีนะครับ วันหน้าผมอาจจะมีโอกาสไปเป็นลูกค้า้บ้างก็ได้ถ้าปีหน้า defend งบได้มากๆ สรุปแล้วก็ Happy ที่ได้ผ่านเหตุการณ์อันไม่คาดฝันแล้วพยายามแก้ปํญหาไปได้ถึงแม้ว่า จะช้าไปมาก ปัญหามา ปัญญาก็มี ความรู้ก็ได้มากขึ้น กำไรเห็นๆ

---

พูดถึง TMI 2005 นิดนึงว่าปีนี้ค่อนข้างเงียบเหงาไปหน่อย อาจจะเป็นเพราะว่า ขาใหญ่ คือ Intel ไม่ได้เป็น titanium sponsor กลายเป็น Sun Microsystem ไปซะ บูตก็เลยน้อย พริตตี้ก็เลยพลอยน้อยไปด้วย (สาเหตุใหญ่ที่ชอบไปงานคอม เหอ เหอ)

ผ่านเรื่องที่ซีเรียสมาแล้วก็มาเล่าเรื่องที่เบาๆ กันหน่อย เดือนก่อน (พ.ย.) ผมมีโอกาสเดินทางไปต่างจังหวัด (พิจิตร) ซึ่งมีคำขวัญประจำจังหวัดว่า "ถิ่นประสูติพระเจ้าเสือ แข่งเรือยาวประเพณี พระเครื่องดีหลวงพ่อเงิน เพลิดเพลินบึงสีไฟ ศูนย์รวมใจหลวงพ่อเพชร รสเด็ดส้มท่าข่อย ข้าวเจ้าอร่อยลือเลื่อง ตำนานเมืองชาละวัน" ครั้งแรกเมื่อวันที่ 19 ก็ไปเยี่ยมญาติน่ะครับ เป็นน้องของแม่ยาย แกไม่สบายป่วยเป็นมะเร็งที่ทรวงอก ออกเดินทางกันเช้ามืดวันที่ 19 ประมาณตีห้าครึ่งมีผม แม่ของเด็ก แล้วก็เด็กๆ ไปแวะรับ แม่ยายกับพี่ของแม่ยายอีกรวมเป็น 6 คนผู้ใหญ่ 4 เด็ก 2 ครั้งแรกที่ก็ไปเริ่มต้นที่อำเภอเถิน แล้วก็เดินทางจากอำเภอเถินเข้าสู่อำเภอทุ่งเสลี่ยมจังหวัดสุโขทัย ตามทางหลวงหมายเลข 1048 เมื่อยังอยู่ในเขตอำเภอเถิน เป็นเส้นทางที่ค่อนข้างชำรุด แคบ เปลี่ยว และคดเคี้ยว ไม่เหมาะในการเดินทางในกลางคืน ต่อเมื่อเข้าสู่เขตอำเภอทุ่งเสลี่ยมแล้วค่อยดีขึ้น ก็มองเห็นสภาพชีวิตของชาวบ้านในฤดูเก็บเกี่ยว เริ่มเห็นรถอีแต๋นแล่นขนข้าว กันค่อนข้างหนาตา ถึงอำเภอสวรรคโลก ก็ใช้เส้นทางหมายเลข 101 ถึงอำเภอศรีสำโรงแวะกินข้าวเช้ากัน ช่วงตั้งแต่สวรรคโลกมาถึงศรีสำโรงก็เริ่มเห็นว่าการชลประทานที่นี่ดีมาก ปลูกข้าวนาปรังกันเขียวขจีเต็มทุ่งนาไปหมด จากศรีสำโรงไปสุโขทัยก็ใช้เวลาไม่นานมากนัก ผมเลือกใช้เส้นทางเลี่ยงเมือง เนื่องจากไม่อยากเข้าไปหลงทางในตัวเมืองสุโขทัย มุ่งสู่อำเภอกงไกรลาศด้วยทางหลวงหมายเลข 12 ยาวถึง จังหวัดพิษณุโลก ซึ่งบางช่วงก่อนที่เข้าตัวเมืองพิษณุโลกมีการปรับปรุง เพื่อขยายทำให้การเดินทางช้าลงไปพอสมควร ทีนี้ก็มุ่งหน้าไปจังหวัดพิจิตร ด้วยเส้นทางสายเลี่ยงเมืองอีกเช่นเคย โดยจุดหมายอยู่ที่ อำเภอวชิรบารมี จังหวัดพิจิตร ตามทางหลวงหมายเลข 117 ผ่านมหาวิทยาลัยนเรศวร ผ่านนิคมอุตสาหกรรมภาคเหนือตอนล่าง แล้วก็เลี้ยวซ้ายเปลี่ยนไปใช้ทางหลวงหมายเลข 115 เข้าสู่อำเภอสามง่าม อำเภอเมืองจังหวัดพิจิตร จากวชิรบารมีถึงพิจิตร เนี่ยเห็นว่าปลูกข้าวนาปรังกันเป็นล่ำเป็นสัน บางแห่งก็เริ่มเก็บเกี่ยวด้วยรถเกี่ยวข้าว บางแห่งก็เริ่มหว่านเมล็ดกล้า บางแห่งต้นกล้าก็เริ่มโต มองดูเขียว ก็ถึงบ้านคลองคู้ อ.เมือง สิ้นสุดการเดินทางเมื่อเวลา 11 นาฬิการวมใช้เวลา 5 ชั่วโมงกว่าๆ ก็ค้างคืนซะคืนหนึ่ง รุ่งเช้าก็พาเด็กๆ ไปเที่ยวดูปลาที่บึงสีไฟ ก่อนเดินทางกลับ ซึ่งกว่าเด็กๆ จะยอมกลับเนื่องจากเพลินกับการให้อาหารปลาที่บึงก็ปาเข้าไปเที่ยงวันพอดี ขากลับผมไม่ได้กลับทางเดิมเนื่องจากรู้สึกว่ามันขับลำบาก อีกอย่างนึงก็คืออยากจะลองเดินทางอีกเส้นทางหนึ่ง คือจาก พิจิตร ตามทางหลวงหมายเลข 115 ผ่านสามง่าม วชิรบารมี เข้าสู่ จังหวัดกำแพงเพชร ช่วงนี้เป็นทางตรงยาวสุดลูกหูลูกตา รถราก็พอประมาณ ไม่ชุมมากนักอาจจะเป็นเพราะช่วงเที่ยง ก็เป็นได้ ทิวทัศน์ข้างๆ ทางก็เป็นนาปรัง สลับกับไร่อ้อย ให้เห็นเป็นระยะ บังเอิญฟังวิทยุอยู่ ดีเจเหมือนจะรู้ใจ เปิดเพลง ไร่อ้อยคอยรักของ หนู มิเตอร์ ก็ทำให้นึกภาพได้ชัดเจนมากขึ้น จากถนนหมายเลข 115 ก็มาบรรจบกับถนนพหลโยธิน (หมายเลข 1) ก็ใช้เส้นทางนี้ต่อจนถึงอำเภอเถิน แล้วก็แยกเข้าอำเภอลี้ด้วยเส้นทางหมายเลข 106 (พหลโยธินเดิม) จนถึงบ้านเวลา 5 โมงเย็น รวมระยะทางทั้งขาไปและขากลับก็ 687 ก.ม. หลังจากนั้นไม่กี่วันประมาณวันศุกร์ที่ 26 ก็ทราบข่าวว่าน้าแกเสียแล้ว การเดินทางครั้งที่สองก็เริ่มขึ้นเมื่อวันอังคารที่ 29 เพื่อไปร่วมฌาปนกิจศพ Trick นี้ผมเลือกใช้เส้นทางสาย เถิน ตาก กำแพงเพชร พิจิตร แทนทั้งขาไปและกลับ รู้สึกว่าขับได้สะดวกกว่าและเส้นทางไม่ซับซ้อนมากนัก พื้นผิวการจราจรก็ดีทีเดียว แต่ไปคราวนี้ไม่ได้ไปค้าง ไปเช้าเย็นกลับ ซึ่งเริ่มที่ 8 โมงเช้าหลังจากที่ไปส่งเด็กๆ ที่โรงเรียนก่อน ตอนเย็นก็ฝากเด็กๆ ไว้กับ ปู่-ย่า ไปก่อน เพราะคิดว่าคงจะกลับถึงบ้านดึก ซึ่งก็กว่าจะทำพิธีก็ปาเข้าไปสามโมงเย็น แต่พิธีการค่อนข้างรวบรัดไม่เยิ่นเย้อเหมือนพิธีทางเหนือ ซึ่งเริ่มประมาณ บ่ายโมง แต่กว่าจะเสร็จก็ปาเข้าไปสามสี่โมงเย็น ทางภาคกลางไม่นิยมจูงศพ ไปที่ป่าช้าเหมือนภาคเหนือ เนื่องจากที่วัดมักจะมีเมรุอยู่ในวัดเลยทำให้ลดเวลาลงไปได้เยอะ แต่ถึงกระนั้นกว่าจะได้เวลาเดินทางกลับก็ไปเข้าไป 17.30 น. ขากลับก็ไม่สามารถใช้ความเร็วมากนักเนื่องจากไม่ได้เอารถเก๋งที่ใช้ทุกวันไป เนื่องจากคิดว่าน่าจะเอารถกระบะไปจะดีกว่า ญาติพี่น้องจะได้ไปด้วยกันหลายๆ คน (แฟนผมเนี่ยญาติเยอะ) ผมก็รับหน้าที่โชเฟอร์ไปคนเดียว กว่าจะถึงบ้านก็ปาเข้าไปตั้ง 5 ทุ่มกว่าๆ เกือบเที่ยงคืน เนื่องจากเหยียบไม่ไหว บรรทุกหนัก ขากลับนี่ได้ส้มท่าข่อยมาหลายสิบลูก แค้นที่ไปครั้งก่อนหาซื้อไม่ได้ 5555 รสชาดก็สมกับคำขวัญของจังหวัดเค้าล่ะครับ หวาน ชุ่มคอดี ถ้ามีโอกาสไปอีกจะไปเหมาสวนเลยล่ะ ตั้งใจไว้อย่างนั้น หรือว่าจะเอาลำไยไปแลกเอา อิ อิ ระยะทางไป-กลับก็ 666 กิโลเมตร พอดิบพอดี

เกือบเดือนที่ไม่ได้มาบล็อก เนื่องจากสาละวนอยู่กับการเตรียมการแก้ไขปัญหาที่พบจากบล็อกเมื่อเดือนก่อน ว่าจะยังยื้ออยู่กับ PostgreSQL 7.4.7 อยู่ หรือว่าจะใช้เวอร์ชั่นใหม่กว่าคือ 8.0.x ตามที่ทางทีมงานแนะนำซึ่งชาวบ้านชาวช่องที่ขึ้นระบบไปแล้วเค้าก็ใช้กัน ไอ้เราจะมาดันทุรังใช้ต่อหรือ คิดอยู่ คิดทบทวนตั้งนาน ก็ต้องยอมอัพ PostgreSQL ไปใช้ 8.0.x ให้เหมือนๆ กัน เวลาคุยกันกับทีมงานจะได้คุยกับเค้าได้ เป็นคำตอบสุดท้าย...

---

ตัดสินใจว่าจะใช้ PostgreSQL แบบคอมไพล์จากซอร์สดีกว่า เนื่องจากยังไม่อยากจะอัพดิสโทรไปเป็น Etch ประกอบกับทดสอบแล้วบนเครื่องที่ใช้ทำงาน ว่า Sarge+PostgreSQL 8.0.3 (Compile เอง) มันก็เวอร์คดีไม่มีปัญหา สิ่งที่ไม่ได้คิดว่าจะเป็นปัญหาแม้แต่น้อยก็คือว่า เมื่อจัดการ apt-get remove --purge postgresql บนเครื่องที่ใช้งานจริง + เครื่องที่ใช้ทำดาต้าเบสมิเรอร์ ตามขั้นตอนต่อไปนี้

db :~/tmp/postgresql-8.0.3/#./configure --prefix=/usr/local/pgsql
db :~/tmp/postgresql-8.0.3/#make
db :~/tmp/postgresql-8.0.3/#make install
db :~/tmp/postgresql-8.0.3/#mkdir /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/#chown -R postgres.postgres /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/#chmod -R 700 /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/#su postgres
db :~/tmp/postgresql-8.0.3/$/usr/local/pgsql/bin/initdb -E UNICODE -D /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/$exit
db :~/tmp/postgresql-8.0.3/#nano -w contrib/start-scripts/linux
db :~/tmp/postgresql-8.0.3/#cp contrib/start-scripts/linux /etc/init.d/postgresql-8.0
db :~/tmp/postgresql-8.0.3/#chmod 700 /etc/init.d/postgresql-8.0
db :~/tmp/postgresql-8.0.3/#/etc/init.d/postgresql-8.0 start

ต่อไปก็เป็นการสร้างดาต้าเบส ดัมพ์ฐานข้อมูลเดิมกลับเข้าไป อัพเดทด้วย SQL สำหรับใช้กับเวอร์ชั่นสาม ทั้งสองเครื่องใช้เวลาไม่นานมากเท่าไรประมาณชั่วโมงกว่าๆ พร้อมกับทำดาต้าเบสมิเรอร์ด้วยแหละ อะไรจะขนาดนั้น จากที่เริ่มต้นปิดระบบตอนประมาณ 3 ทุ่มๆกว่าเสร็จก็ 4 ทุ่มกว่าๆ ของคืนวันที่ 30 พ.ย 2548 ก็เดินลงมาบอกน้องพยาบาลเวรให้เริ่ม login เข้าทำงานได้ อิ อิ พอเริ่มเปิด visit ผู้ป่วยบันทึกอาการเจ็บป่วยเสร็จ พอจะสั่งยาเท่านั้นแหละ ค้นหารายการออเดอร์ไม่เจอ ตอนนั้นยังไม่ซีเรียสอะไรมาก ลองโทรไปถามเบะซะหน่อย คำตอบที่ได้รับปรากฏว่า postgres ไม่สนับสนุนการใช้งานแบบ multibyte ทำให้ค้นหารายการออเดอร์ไม่เจอ เป็นเหตุการณ์เดียวกันกับที่ ชุมแสง และเป็น Critical มากเลยสำหรับซอพท์แวร์ที่เกี่ยวกับการให้บริการสุขภาพ ถ้าสั่งยาไม่ได้ก็แทบจะไม่มีความหมายอะไร ไม่ได้เป็นแค่เซอร์เวอร์ที่ใช้บริการจริงๆ นะ ตัวที่ทำเป็นมิเรอร์ก็เป็นไปกับเค้าด้วย โอ จอร์ช มันยอดมากเลย มีทางแก้มั๊ย อากาศตอนสี่ทุ่มกว่าๆ ที่ทุ่งหัวช้างก็เย็นมากแล้ว แต่ทำไมผมรู้สึกร้อนๆ เหงื่อเต็มฝ่ามือไปหมด ที่ชุมแสงแก้ปัญหาโดยเปลี่ยนจากเดเบียนไปเป็น Redhat Enterprice ที่เบะติดเอาไปด้วยแล้วคอมไพล์ postgres ใหม่ก็สามารถทำงานได้ปกติ เอ้อแล้วกรู จะไปเอา Redhat Enterprice มาจากไหนฟะ ดึกดื่นขนาดนี้แล้ว อย่าว่าแต่ดึกๆ เลย กลางวันแสกๆ ยังไม่มีปัญญาไปหา Distro อื่นหรอก ก็คบเดเบียนมานานโขแล้วจนไม่คิดที่จะใช้อย่างอื่น ก็มีแต่เดเบียน เอ๊ะแต่ทำไมทองแสนขันถึงใช้เดเบียน+postgresql คอมไพล์ได้ว่ะ เริ่มมีกำลังใจมานิดๆ แต่ตอนนี้มันห้าทุ่มกว่าๆ แล้วจะโทรไปถามก็ดึกมาก ไม่เป็นไรลองคอมไพล์ใหม่เพิ่ม option --enable-multibyte ไปด้วยซะ ก็ตอนแรกๆ ที่ใช้ Postgres ก็ใช้แบบคอมไพล์นี่แหละ แต่ตอนนั้น option เยอะกว่านี้มากจำไม่ได้แล้ว จำได้แค่ว่าใช้ Linux SIS + PostgreSQL 7.1.3 ก็ใช้มาตลอดตั้งแต่เดือน ตุลาคม 2545 (เริ่มใช้ Hospital OS เวอร์ชั่นแรกๆ) จนถึง มกราคม 2548 ก็เปลี่ยนมาใช้เดเบียนซึ่งยังไม่ stable+PostgreSQL ที่มากับ Distro พร้อมๆกับ upgrade มาเรื่อยจน Sarge กลายเป็น Stable และ PostgreSQL หยุดอยู่ที่ 7.4.7 กลับมาที่การคอมไพล์ครั้งที่สองบวก option --enable-multibyte ไปด้วยผลออกมาก็คือยังไม่สามารถใช้งานได้ มาถึงตอนนี้เริ่มเครียดเนื่องจากว่าเข้าสู่วันใหม่แล้ว โชคดีที่เวรดึกไม่มีผู้มารับบริการเลยทำให้ตัดความกังวลไปได้บ้าง คิดว่าจะต้องลงเดเบียนใหม่อีกที ทีนี้ขออัพเกรดไปเป็น Etch เพื่อเลือกใช้ PostgreSQL 8.0.3 ที่มากับ Distro อาจจะตัดปัญหาเรื่อง multibyte ไปได้ (คิดอะไรไม่ออกแล้วตอนนี้ต้องเสี่ยง) เสร็จประมาณตีสามกว่ารวมเวลาที่คอยการ fetch package จากอินเทอร์เน็ตด้วย เน็ตก็ไม่ค่อยเป็นใจเท่าไร โอยกว่าจะก้าวหน้าที่ละ k ใจจะขาดซะให้ได้ ผลที่ออกมาน่ะเรอะ เหอะ เหอะ เหมือนเดิม ตอนนี้เครียดกว่าเดิมอีก เหลือเวลาอีกไม่กี่ชั่วโมงก็จะสว่างแล้ว แล้วยังมีคลินิคเบาหวานด้วย โอ จอร์ช พระเจ้าจะช่วยกรู ได้ไหมฟะเนี่ย ทำงัยดีล่ะ เอางี้แล้วกันถอยกลับไปใช้เวอร์ชั่นสองอีกครั้ง เอาเครื่องที่เป็นมิเรอร์นั่นแหละ ให้บริการไปก่อน ลืมบอกไปว่าหลังจากที่พบว่ามีเออร์เรอร์เรื่อง multibyte ผมก็เอา PostgreSQL 8.0.3 ที่คอมไพล์บนเครื่องมิเรอร์ออก แล้วก็กลับไปใช้ 7.4.7 เหมือนเดิมปรากฏว่าไม่มีเออร์เรอร์เรื่อง multibyte แฮะ อย่างน้อยก็ยังอุ่นใจได้อย่างน้อยก็สักวันหนึ่ง แต่จะหวังให้ใช้งานหนักๆ เร๊อะ คงยากเนื่องจากสเปคของ Hardware เป็นสเปคของ Desktop PC ธรรมดาลำพังการเอามาทำเป็นมิเรอร์เนี่ยก็ค่อนข้างโหลดมากแล้ว มองดูนาฬิกาอีกทีตีสามกว่าเกือบตีสี่แล้ว เอาเป็นลงเดเบียนอีกทีน่ะ คราวนี้เอา Sarge เหมือนเดิมก็แล้วกันแล้วคอมไพล์ PostgreSQL เอา ลองดูอีกทีน่ะยังพอมีเวลา ทีนี้ตอนลงเพิ่ม Repository ของ update เข้าไปด้วยตีห้ากว่าๆ ก็เสร็จ ตอนที่ login เข้าไปเทสต์น่ะ ผมงี้ลุ้นใจจะขาด ในที่สุดสวรรค์ยังเมตตา ไม่ให้ผมต้องรับกรรมไปมากกว่านี้อีก กว่าจะเริ่ม fine tunning , set up crontab อีกสว่างคาตาเลยครับ คำพูดที่ว่าฟ้าเหลืองน่ะ มีจริงผมยืนยันได้ เจอกับตัวเองเข้าถึงรู้ เหอ เหอ

---

ปัญหาที่เกิดขึ้นผมพอจะเดาเอาเอง ซึ่งอาจจะไม่ใช่สาเหตุจริงๆ ก็ได้

1. Sarge ที่ติดตั้งบนเครื่อง Database Server ไม่ได้ update เลยอาจทำให้บางแพคเกจมีปัญหาในการใช้งาน PostgreSQL+mutibyte


2. เครื่องที่ทำเป็น Database Mirror ผมมักจะใช้เป็นเครื่องที่ทดลองการใช้งาน Debian อยู่เสมอและเปิดการอัพเดทด้วยทำให้ไม่มีปัญหากับ multibyte เมื่อใช้กับ Postgres 7.4.7 แม้ว่าจะคอมไพล์ 8.0.3 ไม่ผ่านแต่ก็สามารถ Down ลงมาใช้ของเดิมได้


3. Etch ไม่มีระบบการ update security เนื่องจากยังอยู่ในการ Testing บางทีอาจจะยังไม่พบปัญหานี้ก็ได้ เป็นปัญหาของเดเบียนหรือว่า Postgres กันแน่ ?

อย่างไรก็ดี เหตุการณ์เหล่านี้ก็ผ่านไปแล้วด้วยดี โรงพยาบาลก็สามารถให้บริการต่อได้ด้วย HospitalOS Version III ก็ต้องขอขอบใจน้องๆ ที่อยู่เวร คอยเป็นกำลังใจให้ ผมเองตอนเช้าเมื่อเห็นจุดบริการต่างๆ สามารถใช้งานด้วยความราบรื่นก็ดีใจ ที่เราในฐานะของฟันเฟืองชิ้นเล็กๆ ชิ้นหนึ่งในระบบ มีส่วนทำให้กลไกการทำงานสามารถก้าวหน้าต่อไปได้ ไม่ติดขัด แม้ว่าจะไม่มีใครรู้ ใครเห็น ก็ตามก็เป็นความสุขที่ได้ทำ นี่หรือคือชีวิตของผู้ดูแลระบบ ชีวิตที่อยู่เบื้องหลังความสำเร็จของการให้บริการ (ว่าเข้าไปนั่น)

ทีนี้ก็เหลือภาระงานอีกอย่างที่ต้องรีบเร่งทำ คือการทำมิเรอร์ ให้กับ Database จากประสบการณ์ที่ผ่านมาทำให้ไม่วางใจในเซอร์เวอร์เพี่ยงเครื่องเดียว คงต้องเหนื่อยอีกรอบ สู้โว๊ย