PostgreSQL 影片

Loading...
Google

2007-05-15

【PostgreSQL观察】第36回 PostgreSQL的安全补丁(三)(简体)

更新:2007-05-15
對映章節:
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270174/?ST=oss&P=3

按照石井先生的惯例,最后要讲些别的。

停止支持Windows平台下的PostgreSQL 8.0、8.1
理由主要是开发人员的不足,另外8.2版本特别针对Windows平台的固有问题进行了大规模的改良,难于向8.0、8.1移植也是一个很重要的原因。
不过并不是现在马上截止,而是从正在开发中的8.3正式发布起停止。由于PostgreSQL 8.3最早于2007年07月正式发布,在此之前还会进行少量的维护工作。
总之,Windows平台下的8.0、8.1的用户,最好从现在就考虑向8.2的移植吧。

正在开发中PostgreSQL 8.3的状况
关于8.3的最新状况,本来已经进行完功能确定的工作,大量的新功能和改良必须提交到cvs上。但是以上次提到的HOT为代表的大型功能比核心开发人员考虑的要多,目前进度落后。

PostgreSQL Conference 2007
从去年开始的PostgreSQL Conference,今年5月21-24日在渥太华举行(21-22日是tutorial)。延续自去年,仍然安排来自PGCluster的三谷先生的讲座。

关于PostgreSQL Conference 2007的详细资料:
http://www.pgcon.org/2007/

我预计也会参加,下次的“PostgreSQL观察”将为大家传达会议的情况。

(最后一篇内容本来不少,因为中间相当篇幅讲DISCARD命令,与前边从BLOG翻译来的一样,所以略过)

2007-05-14

PostgreSQL 的優點不應該受限於購買商業書籍的人數!

阿益我這幾天無事亂想...
決定不找出版商了!
但書的撰寫仍會開始進行,
並且在本站的頂部列了撰書專屬的內容討論區與(PDF)下載點.
目標和進度將更加公開(預計同時進行正體中文版與簡體版本)

阿益個人的理由是:
商業出版雖然可以讓小弟賺到一點小利與聲望,
但另一方面卻等同把 PostgreSQL 的知識與更廣的推廣工作,
受制於必須付費購買受地區限制(台灣)的商業出版書籍的閱讀人數,
阿益深感這違背了自己當初投入決定協助 PostgreSQL 在中文社群上推廣的精神.

若能採用網路圖書的方式來推廣,
也許更能使這本書的內容傳播到包括中國, 香港, 台灣..更多中文華人手上,
再加上 PG 中國的PostgreSQL技術討論區與本站的網誌, 在三者並行的推廣情況下,
期待更多專業的華人技術員參與 PostgreSQL 的全球開發團隊,
讓 PostgreSQL 能不斷的邁向全球最先進的開放源資料庫系統!!!

延伸閱讀(Link):

2007-05-13

【PostgreSQL观察】第36回 PostgreSQL的安全补丁(二)(简体)

更新:2007-05-13
對映章節:
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270174/?ST=oss&P=2

利用临时schema的攻击
PostgreSQL具有“临时表”功能,仅在session期间有效,可以被短时间使用。这些临时表放在一个特殊的数据表“临时schema”中,同样包含在pg_catalog中,比其他schema优先被搜索。
也就是,利用pg_catalog进行同样方式的攻击是可能的,这就是这次新发现的安全脆弱性。
这个安全漏洞的编号是CVE-2007-2138

难于对策的利用临时schema的攻击
可以采取与上次同样的对策,设定适当的schema搜索路径,但是这里有一个问题:临时schema的名字不是固定的。
在psql中利用\dn命令看一下就可以知道这一点:
test=> CREATE TEMP TABLE t1(io int);
CREATE TABLE

test=> \dn
  List of schemas
  Name      | Owner
--------------------+---------
information_schema  | t-ishii
pg_catalog      | t-ishii
pg_temp_1      | t-ishii
pg_toast       | t-ishii
public        | t-ishii
(5 rows)

pg_temp_1就是临时schema,“_1”部分是根据session变化的。

假想schema名「pg_temp」的引进
本次的安全性补丁引进了表示临时schema的假想schema叫做“pg_temp”,将它放在schema搜索路径的最后就可以。
从上边的说明可以看出,这个安全对策仅仅做PostgreSQL的版本升级是不够的,在使用SECURITY DEFINER函数的地方必须修正schema搜索路径明确指定使用pg_temp。
详细情况可以查阅PostgreSQL技术手册中的CREATE FUNCTION命令,慎重起见在这里预先说明一下。另外,这里
的函数是用PL/pgSQL编写。

(1)保存现在的schema搜索路径、设置新的路径:
old_path := pg_catalog.current_setting('search_path');
PERFORM pg_catalog.set_config('search_path', 'admin, pg_temp', true);
在函数的最开始增加这两行代码。
关键点是,schema搜索路径仅仅包含用户不能创建对象的schema(例子中是admin),而pg_temp要放在最后。因为public schema任何用户都可写入,搜索路径中最好不要包含它。函数中使用public对象的地方,显式地使用schema修饰符,例如:public.t1。
set_config()最后的参数为true,意味着当函数中发生错误而将事务中断的时候,将重新设定的schema搜索路径返回原始设置。这个也是很重要的。

(2)执行通常的函数处理
没什么特别的变动。

(3)
将schema搜索路径返回初始设定
PERFORM pg_catalog.set_config('search_path',old_path,true);
这个要写在return语句前边。

新发布的版本
实现以上对策的版本是:8.2.4、8.1.9、8.0.13、7.4.17、7.3.19,如果正在使用SECURITY DEFINER函数的话,尽快作版本升级是非常必要的。再者,单纯做版本升级是没有用的,必须注意还需要修改函数。因为SQL函数难于对应,使用PL/pgSQL将它重写吧。
另外,本次发布的补丁包括VACUUM FULL可能破坏数据等比较重要的bug修正,即使没有使用
SECURITY DEFINER函数,也推荐进行版本升级。

2007-05-12

【PostgreSQL观察】第36回 PostgreSQL的安全补丁(一)(简体)

更新:2007-05-12
對映章節:
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270174/

翻译自石井达夫先生的文章

新的安全漏洞
在PostgreSQL观察第35回,传达了来自核心开发成员的安全补丁发表预告以及关于SECURITY DEFINER函数(可以使用其他用户权限的函数)的安全警告,这次新发现的安全漏洞正是与SECURITY DEFINER有关。

SCHAMA搜索路径(search path)的问题
在讨论本次发现的安全漏洞之前,我们先复习一下上回提到的“安全警告”,他们的根源是一样的。
PostgreSQL中有Schema的概念,也就是命名空间,在不同的schema中可以创建名字相同的数据表,这就像在UNIX中可以在不同目录下创建同名文件一样。它有两种用法:
一种是显式指定schema名:public.t1指定public schema下的t1对象。
另一种方法是 使用schema search path,指定当省略schema名称的时候,优先使用哪一个schema。可以用“show search_path”命令来确认当前的 schema search path:
test=> show search_path;
search_path
----------------
"$user",public
(1 row)
这个例子显示以当前登陆用户名为第一优先schema名称,然后是名为public的schema。顺便提一下public这个特殊schema,它是缺省的schema,如果什么也不指定的话,对象将被建立在public中。

利用pg_catalog schema的攻击
除此之外还有持有系统catalog、聚集函数(aggregate)、操作符(operator)的pg_catalog schema,即使它没有包含在搜索路径中一般也被当作搜索对象,并经常被最先搜索。因为所有的聚集函数和操作符都被pg_catalog持有,这样的考虑是适当的。
但是如果显式将pg_catalog放到搜索路径中的话,将以指定的顺序进行搜索。如果事先准备与pg_catalog中的聚集函数和操作符同名的对象,pg_catalog中登录的“正规”对象会被替代。这样,SECURITY DEFINER函数中使用的对象可以被替换为恶意用户提供的对象,以他人的权限实施攻击。
相应的对策是,在SECURITY DEFINER函数的搜索路径中仅仅设定安全的schema。
上次说提出的“安全警告”正是这样。

2007-05-11

決定找出版社談談囉~PostgreSQL 8.3 目錄(暫定)

這是預定的內容, 各位如果有好的出版商麻煩介紹一下囉~
明天起來去打電話問問出版社...
各位朋友順便幫阿益看看內容給點建議~
感謝您^.^

PostgreSQL 8.3 目錄(暫定)

第一部份 PostgreSQL基本知識篇 5

Chapter 1. PostgreSQL 全球最先進的開放源碼資料庫系統 5

1.1. 什麼是 PostgreSQL ? 5

1.2. 歷年國際上獲獎的證明 5

1.3. 長達21年嚴謹的發展歷史 5

1.4. 能在最多種作業系統平台上運行 5

1.5. 免費且自由的使用授權與完全公開源碼 5

1.6. 先進的物件導向型資料庫系統 5

1.7. 唯一完全屬於社群構建的企業級資料庫系統 5

1.8. 最服從國際SQL標準規範開發的模範生 5

1.9. 擁有最寬廣的程式語言中介體 5

1.10. 允許使用者自訂函數 5

1.11. 完整的國際化支持 5

1.12. 全文搜尋功能 5

1.13. XML的支持 5

1.14. 超越商業型資料庫系統的權威測試報告 5

1.15. 通過國際 ISO15408 軟體品質安全性認證 5

1.16. 全球大型組織使用中的品質實例 6

Chapter 2. 許可執照 6

2.1. BSD 許可執照的特徵 6

2.2. PostgreSQL 為核心商業化的國際型企業 6

2.2.1. EnterpriseDB, Inc. 6

2.2.2. Command Prompt, Inc. 6

2.2.3. Fujitsu Supported PostgreSQL (FSP) 6

Chapter 3. 從舊版本到新版本間的改變 7

3.1. 版本7.4到版本8.0的改變 7

3.2. 版本8.0到版本8.3的改變 7

Chapter 4. 關聯型資料庫的基本知識 7

4.1. 關聯型資料模型的基本概念 7

4.2. 資料庫管理系統的角色 7

4.3. SQL國際標準(SQL92, SQL99, SQL2003) 7

4.4. SQL基礎理解, SQL分組化(DDL/DML/DCL) 7

第二部份 PostgreSQL 伺服器管理篇 7

Chapter 5. 安裝方式 7

5.1. initdb 命令 7

5.2. 資料庫叢集的概念 7

5.3. 樣版資料庫 7

Chapter 6. 標準工具的使用方法 7

6.1. psql, pg_ctl, postmaster, createdb, dropdb, createlang, droplang, createuser, dropuser, vacuumdb 7

Chapter 7. 組態配置文件檔 7

7.1. postgresql.conf 7

7.2. pg_hba.conf 7

7.3. SET/SHOW 宣告的使用 7

Chapter 8. 備份策略 8

8.1. 使用 pg_dump, pg_dumpall, pg_restore, psql 命令 8

8.2. 複製資料目錄夾的備份與還原 8

8.3. PITR 的概念 8

8.4. 使用COPY 宣告與 copy 命令 8

Chapter 9. 管理者基本任務 8

9.1. 創建/刪除/變更資料庫使用者 8

9.2. VACUUM/ANALYZE 的使用與預算 8

9.3. 系統摘要資訊的取得 8

9.4. 資訊架構模式與系統目錄 8

9.5. 權限表上GRANT/REVOKE 宣告 8

第三部份 PostgreSQL 程序開發篇 8

Chapter 10. SQL 命令 8

10.1. SELECT 宣告 8

10.2. INSERT/UPDATE/DELETE 宣告 8

10.3. 序列數(Sequences) 8

10.4. 資料類型 8

10.5. 二進制陣列類型與大型物件 8

10.6. 表的定義 8

10.7. ALTER TABLE, DROP TABLE, CREATE TABLE AS 8

10.8. 索引 9

10.9. 視觀表(Views) 9

10.10. 規則系統與觸發器 9

10.11. 架構模式(Schemas) 9

10.12. PREPARE 9

10.13. 游標(Cursor) 9

10.14. 共同值域(Domain)與類型定義 9

10.15. 函數定義與PL/pgSQL 9

Chapter 11. 建構函數 9

11.1. 聚合函數 9

11.2. 算術函數與運算子 9

11.3. 字串函數 9

11.4. 字串運算子 9

11.5. 時間函數 9

Chapter 12. 事務交易概要 9

12.1. 事務交易的宣告 9

12.2. 事務交易隔離層級 9

12.3. (LOCK) 9

12.4. LISTEN/NOTIFY 宣告 9

Chapter 13. 與程式語言建立連線 9

13.1. C libpg 10

13.2. Java JDBC 10

13.3. Ruby 10

13.4. Perl 10

13.5. PHP 10

13.6. .NET ODBC 10

第四部份 PostgreSQL圖形化管理介面(GUI) 10

Chapter 14. pgAdmin III 1.8 10

14.1. 取得與安裝 10

14.2. 介面與功能介紹 10

Chapter 15. phppgadmin 4 10

15.1. 取得與安裝 10

15.2. 介面與功能介紹 10

Chapter 16. 商業軟體簡介 10

16.1. Navicat PostgreSQL 10

16.2. EMS PostgreSQL Manager 10

第五部份 PostgreSQL 龐大的關聯軟體專案庫 11

Chapter 17. PgFoundry GBorg 簡介 11

Chapter 18. 主要子專案 11

18.1. Slony-I 複寫叢集系統 11

18.2. pgpool-II 負載平衡叢集系統-複寫-連結池 11

18.3. pgCluster 同步多點叢集系統 11

18.4. 常用子專案功能說明索引 11

附錄 11

A. PostgreSQL CE 認證考試 11

B. Windows 環境的安裝 11

C. 網路資源 11

D. 本書附屬的CD-ROM 11

2007-05-08

我論 PostgreSQL 在日本受到的重視與研究發展

更新:2007-05-08
對映章節:

內容:
經過了一段時間"向上教育", 終於能讓 Boss 定案,
讓 PostgreSQL 正式進入教育課程專案,
並配合 PostgreSQL CE - 國際認證考試 來推入市場,
阿益我開始進行整理估計近百小時的上課教材...

一方面我感到高興...
因為小小的我終於能替 PostgreSQL 做出實質的推廣教育,
但同時也感到大中華區落後日本對 PostgreSQL 重視程度是如此的大.
這樣棒的 DBMS 竟然被佔全球 1/4 人口的華人所忽視投入...

在日本...

在國際市場上...
聯合國-企業發展組織, 美國國家氣象服務中心...
PostgreSQL [應用實例]荷蘭國家人口註冊管理系統的改寫
Sun-PostgreSQL 勝利獲得 Oracle 的客戶
Skype 捐獻 PostgreSQL code 三個子專案
由 EnterpriseDB 論數據庫開源模式
(與Oracle資料庫相容的EnterpriseDB)
EnterpriseDB 獲選為Linux商業應用大獎-最佳企業級資料庫

更完整的 PostgreSQL 企業使用名單與簡報(國際官網)

延伸閱讀(Link):
為什麼選用 PostgreSQL,而不是 Oracle?
PostgreSQL 整體擁有成本(TCO)
PostgreSQL 資助開發主辦者公司名單
PostgreSQL CE 8 銀級認證 - 詳細考試範圍

Windows版本下的参数max_stack_depth(简体)

更新:2007-05-08
對映章節:

內容:
前几天一位朋友跟我讨论max_stack_depth在windows下的调整,调查到一点东西,整理一下共享给大家。

因为着重讲max_stack_depth在windows的问题,所以没有翻译参数说明:
max_stack_depth (integer)
Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines such as expression evaluation. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it may be too small to allow execution of complex functions. Only superusers can change this setting.
Setting max_stack_depth higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. On platforms where PostgreSQL can determine the kernel limit, it will not let you set this variable to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.

它是在8.0中引入的,摘自8.0的release note:
Server configuration parameter max_expr_depth parameter has been replaced with max_stack_depth which measures the physical stack size rather than the expression nesting depth. This helps prevent session termination due to stack overflow caused by recursive functions.

8.2中的调整:
On platforms that have getrlimit(RLIMIT_STACK), use it to ensure that max_stack_depth is not set to an unsafe value. This commit also provides configure-time checking for , and cleans up some perhaps-unportable code associated with use of that include file and getrlimit().

现在遇到的问题是,在8.1 For Windows能够正常运行的程序,在8.2下由于max_stack_depth的限制变得无法正常值运行。
由于这个校验的存在,Windows平台
max_stack_depth的最大值为3584KB,如果超过PostgreSQL 8.2将无法启动,但是这个3584KB却无法满足程序的需求。而早先在8.1下设置为10M是没问题的,程序运行过程中也不会引起错误。我猜想原因是由于架构的不同,在这个方面设置是不一样的,windows允许超过而*nix不允许,这样移植到windows下以后,依然参照*nix的方式进行校验,导致这个问题的出现。windows不同于*nix,内核参数几乎是不能自行改变的,比如这个RLIMIT_STACK在*nix可以通过微调将它设置为更大,而windows下根本就是个常量,没有任何办法改变。好在看起来windows平台并没有像*nix平台一样将max_stack_depth限制在RLIMIT_STACK大小之内。
问题就在这里,似乎只是个移植问题。

解决办法就是修改源代码
postgres.c的函数assign_max_stack_depth中

long stack_rlimit = get_stack_depth_rlimit();
改为:
#if defined(WIN32) || defined(__CYGWIN__)
long stack_rlimit = 10*1024*1024; //10M
#else
long stack_rlimit = get_stack_depth_rlimit();
#endif

然后重新编译即可

编译请参考:
Compiling PostgreSQL On Native Win32 FAQ
Installing PostgreSQL on Windows Using Cygwin FAQ

本方法没有经过测试,仅供参考,对此本人不承担任何责任。

2007-05-07

DISCARD命令(简体)

更新:2007-05-07
對映章節:
http://postgresql.at.webry.info/200705/article_1.html

內容:
翻译自石井达夫先生的blog,连接见上。

正在开发中的PostgreSQL 8.3追加新命令DISCARD,用来清除连接中session的固有数据,包括以下各项:
1、SESSION AUTHORIZATION(切换到其他用户);
2、SET命令设定的选项;
3、PREPARE生成的plan;
4、打开的cursor;
5、LISTEN生成的对象;
6、plan cache;
7、临时数据表。

3是指到8.2为止没有未命名的plan无法被删除,现在可以一起删除掉。(原文如此,我并没有完全理解,因为PREPARE命令从文档看是必须为plan命名的。也许这里是说的是执行SQL语句时自动生成的plan,哪位仁兄知道请来信指正。)
6是指以session为单位将查询plan放在cache中的功能,这是在8.3中新增的。

DISCARD最有用的可能不是通常的数据库application,而是像pgpool这一类的中间件(middleware)。到目前为止,要特意截获(intercept)PREPARE命令,在自己的session中记录持有的plan,然后在session结束的时候将它们删除,而DISCARD命令的出现可以将这个处理省略。

特别注意的是,DISCARD命令不能在事务块中使用。

2007-05-05

PostgreSQL 的工具小卡(Cheat sheet)

更新:2007-05-05
原始來源:
http://www.alberton.info/postgresql_cheat_sheet.html

內容:
這份小卡是由 Lorenzo Alberton 製作提供.

(點圖放大)


這張小卡(cheat sheet)由4個部份組成.
第一個部份內容是有效的資料類型清單,
他們標示每一個支持的詳細內容及範圍值.

更多不同的格式下載:


延伸閱讀(Link):

從 Oracle 到 PostgreSQL 的 JDBC 概要手冊

更新:2007-05-05
對映章節:
http://www.postgresql.org/docs/techdocs.41

內容:
PGSQL 8.1 for J2EE/JDBC Applications

Robert Treat 是 PostgreSQL 開發團隊的長期的成員之一,
並著作有 Begining PHP and PostgreSQL 8 ,
這份文件是放在 PostgreSQL 國際官網上,
提供給從 Oracle 10g 10.2 版到 PostgreSQL 8.1 遷移過程中,
JDBC 應用的一些改變需求的基礎性概觀.

下載文件(PDF): pg_8.1_J2EE_v1.0.pdf (161.4 kb)





延伸閱讀(Link):

2007-05-03

Ruby 這把火也開始延燒到 PostgreSQL 開發團隊

更新:2007-05-03
對映章節:

內容:
RoR(Ruby on Rails)最近真的大火燒到各地...

(PostgreSQL 8.3 版新增的自動下載附加套件庫程序)
測試版中唯一被加入的 Web 開發架構.
Application stack builder (點圖放大)


Ruby 在今年程序語言排名進了前10名之後,
SUN 公司的 JRuby 也即將進入 1.0 版 Release 階段,
前幾天 Microsoft 公司也即將 join Ruby...

沒想到這把大火也燒進了 PostgreSQL 開發者的天地...



甚至有開發者打算改寫原本以 Perl 撰寫的 PostgreSQL 程序入 Core...
PL/Ruby
(一種可以用 Ruby 在 PostgreSQL 中寫預儲程序的分支語言)


前天安裝最新的 PostgreSQL 8.3 開發測試版,



竟也名正言順的進了 PostgreSQL 的附屬分支首選自動下載軟件庫之中
pgRails (由 EnterpriseDB 公司回饋社群整合)
會自動安裝在本地一個以 PostgreSQL 為後端的 RoR
...


延伸閱讀(Link):

PostgreSQL 8.3 for Win32 測試安裝版(發佈)

更新:2007-05-03
對映章節

內容:
前天(2007-05-01)團隊構建了 8.3 開發中的快照(snapshot)版本, 本月底前將進入品質穩定期, 將不再接受新功能的加入, 僅就當前確定的內容做單元測試, 這個版本提供給 Win32 的使用者搶鮮與方便測試, 請注意本版本屬開發中版本, 勿使用在您的產品上.

新的特點:

  • 數個新容貌及安裝器確定, 自動偵測本地端及較優化的己存在資料目錄.
  • 將 PostgreSQL 商業化的 EnterpriseDB 公司加入回饋整合開發, 讓 PostgreSQL 多了許多可與 Oracle 競爭的好工具.
  • 新的 stackbuilder 系統(類似自動更新/取得附屬功能軟件的功能).
  • pgAdmin III 1.7 快照版(另外還附加阿益&阿亮中文的介面心血...)
  • 新的 8.3 版本將擁有非常多的附屬應用與驅動器.
阿益:
很建議您下載裝看看, 尤其追加的新功能 Application stack builder
將 Linux 系統最方便的自動取得下載與更新附加套件的觀念加入了
(下一篇再來寫心得.)


下載頁:
http://pgfoundry.org/projects/pginstaller/

延伸閱讀(Link):
http://people.planetpostgresql.org/mha/index.php?/archives/147-guid.html

我論 Oracle 對安裝於 Linux 上的要求調校事項(三)

更新:2007-05-03
對映章節:

內容:
再來的以下4個 tuning, 涉及到 net 的 troubleshooting,
Debian 的預設全是同樣值"109568",
根據 Oracle 的值來論, 全屬放大倍數值:

network socket 的接收和傳送緩衝區(buffer)大小

net.core.rmem_default = 1048576 (10 X)
net.core.rmem_max = 1048576 (10 X)
net.core.wmem_default = 262144 (2 X)
net.core.wmem_max = 262144 (2 X)

這4個值能調整伺服器能達到高效能(high performance)的水準,
所以同樣也適用在其它提供高負載單一服務功能的 Linux 版本或主機上.

Oracle 另外對系統安全的資源限制做了放寬調整: limits.conf

oracle          soft    nproc   2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
nproc - 最大進程數量
nofile - 最大開啟檔案數

Debian 的預設值:
nofile 1024, nofile 的最大限制受 fs.file-max 核心變數影響,
預設值為 48938, 其餘並未做限制.

從這點就能看出 Oracle 運行時開啟的檔案數是很嚇人的,
尤其啟動其相關的 java 應用更是, 對身為系統管理員來說,
也增加了管理及安全甚至除錯的因難負荷量, 不見得是件好事
.

延伸閱讀(Link):
Oracle 10g 10.2 官方安裝說明文件(sysctl部份)

2007-05-02

我論 Oracle 對安裝於 Linux 上的要求調校事項(二)

更新:2007-05-02
對映章節:

內容:
Linux 採用 System V 的架構
shm 是 System V 下的 Shared memory 的簡稱
/etc/sysctl.conf 用來開機載入更動核心預設值用

/proc/sys/kernel/ 包含以下的核心映射,
我們來對照一下 Debian testing 版本的預設:

#Total amount of shared memory available (bytes or pages)
"kernel.shmall = 2097152" (= Debian Default)

#Maximum size of shared memory segment (bytes)
"kernel.shmmax = 2147483648"
(> Debina "33554432" , 加大到近 22倍大)(巨大怪獸的證據!!!)

#Minimum size of shared memory segment (bytes)
"kernel.shmmni = 4096" (= Debian Default)

#Maximum number of shared memory segments per process
"kernel.sem = 250 32000 100 128"
(> Debian "250 32000 32 128")

/proc/sys/fs/
最大開啟檔案數量的需求設置(巨大怪獸的證據!!!)
"fs.file-max = 65536" (> Debian "48938")
這個選項與 ulimit 功能有連帶關係...

/proc/sys/net/ipv4/
#加寛非常大量的 local port 長度(巨大怪獸的證據!!!)
"net.ipv4.ip_local_port_range = 1024 65000"
(> Debian 預設寬度 "32768 61000")

#最後就是啟用上述來對 Linux 生效...
/etc/init.d/networks restart
/sbin/sysctl -p


延伸閱讀(Link):
http://www.postgresql.org/docs/8.2/interactive/kernel-resources.html

我論 Oracle 對安裝於 Linux 上的要求調校事項(一)

更新:2007-05-02
對映章節:

內容:
Oracle 對於安裝於 Linux 上使用 Oracle 10g 資料庫系統, 有著官方文件的安裝教學與系統調校的建議事項, 阿益我來改寫成對 PostgreSQL 的類推建議與補足說明:

首先, 前陣子因為客戶需要測試 Oracle 10g 產品, 阿益我看了 Oracle 的文件後, 深感...嗯果真是高貴$和高高要求系統資源的資料庫系統, Oracle 建議採用 RHEL 4 AS 或是 SUSE Enterprise Linux 9+, 商業配商業...夠義氣...

那我只好選用 RHEL 4 AS 的 Free 複製羊版本囉(99.9% 相似度的 CentOS 4.4版)...

經過了一番時間, 照著 Oracle 的要求, 安裝完後, 只有一個感想, 好肥最好單獨 4GB 以上的空間, 來放置整個 Oracle 基礎(不包括每建一個DB時增加的容量哦...), RAM 最好也要1GB以上, 一啟動 Oracle 就連帶快用光 RAM, 再者 Oracle 10g 大量運用 Java 和 Java Server 環境應用...(果然比大象更大象@@")

說完了故事, 開始來看看 Oracle 建議調校 Linux 的系統資源部份(我們學習的重點)
首先老話一句...
安裝資料庫伺服器的主機(Linux)建議停用其它非必要的服務, 最佳的方式就是僅提供單一服務的主機環境來保持最佳效能, 這點在往後建立資料庫叢集化(Cluster)是很必要的哦.

比起 Oracle 10g 的安裝大小, PostgreSQL 就顯的像 RUBY 一樣輕巧了 N 倍...

Oracle 要求修改 Linux 預設的 RHEL 核心參數在開機時生效, 我們要對 /etc/sysctl.conf 進行寫入如下,這也是本篇阿益的重點, 來分析看看為啥 Oracle 要求更動這些核心預設:

echo "kernel.shmall = 2097152" >> /etc/sysctl.conf
echo "kernel.shmmax = 2147483648" >> /etc/sysctl.conf
echo "kernel.shmmni = 4096" >> /etc/sysctl.conf
echo "kernel.sem = 250 32000 100 128" >> /etc/sysctl.conf
echo "fs.file-max = 65536" >> /etc/sysctl.conf
echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf

net.core.rmem_default = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 262144
net.core.wmem_max = 262144
/sbin/sysctl -p

Oracle 的理由是預設的核心資源設定無法滿足 Oracle 10g 的正常運行...


延伸閱讀(Link):
http://www.postgresql.org/docs/8.2/interactive/kernel-resources.html

2007-05-01

pgAdmin III 追加翻譯中文語系檔

更新:2007-05-01
對映章節:

內容:
持續的投入, 果真會讓人收獲多於投入, 總是讓我更佳佩服 PostgreSQL 開發與發展的過程的品質嚴謹與團隊分工合作的能力(以一個完全無商業色彩的OSS來論), 開發團隊上百人散佈在全球, 彼此間80%的人未曾聚會過, 但專案品質與彼此間的溝通默契卻非常OK, 週週都可見 SVN 被 up+ 約 50~100項以上(PostgreSQL SVN).

昨天我追補翻譯了新增的 34 個新字串, 目前總字串數 2091 個,
已加入到 pgAdmin III SVN 中.
想要最新的中文語系檔可到以下位置下載:

http://www.pgadmin.org/translation/status.php

想起當初投入這 pgAdmin III 的翻譯工作,
最初目的是想強迫自己學習它,
一路走來, 想想卻很值得, 因為翻譯過程會看到更細微的 PostgreSQL 開發設計中的架構...

因為在不斷增加的 2000 多個字串的背後, 每一筆字串都是開發團隊想把 PostgreSQL 的全部特性與功能忠實的用 GUI 介面來呈現給您, 告訴您 PostgreSQL 的優秀不需要商業廣告加持!!!

備註:

  1. 最新的語系檔, 必須同步使用 SVN 版本才會顯示新增加的功能中文.
  2. SVN 版目前為 1.7 開發版本, 預計要到今年五月底才會穩定功能, 安定期約到今年七月與 PostgreSQL 8.3 同時發佈(Win32版本會包裹 pgAdmin III 1.8).
  3. 語系檔目前也屬未安定中內容(開發團隊可能會再次更動功能), 所以我先分次完成正體與簡體中文.
題外話:
還是需要更多愛好者加入寫作或是翻譯工作, 請連繫我們或是PG中國.

延伸閱讀(Link):

PostgreSQL & Google-Analytics Running...

::Planet PostgreSQL::

PostgreSQL Information Page

PostgreSQL日記(日本 石井達夫先生Blog)

PostgreSQL News

黑喵的家 - 資料庫相關

Google 網上論壇
PostgreSQL 8 DBA 專業指南中文版
書籍內容討論與更多下載區(造訪此群組)
目錄下載: PostgreSQL_8 _DBA_Index_zh_TW.pdf (更新:2007-05-18)

全球訪客分佈圖(Google)

全球訪客分佈圖(Google)