PostgreSQL 中設置 Tablespace 的注意事項

在 PostgreSQL 中，也有「像」Oracle 資料庫一樣，有所謂的 Tablespace 一詞。不過兩者的概念著實的不一樣。

EDB 功能 - SQL/Protect

有時候，程式開發會使用參數方式組合出 SQL 指令，再往資料庫提請求。但是如果設計有疏忽，沒有對前端使用者的輸入條件進行完整的檢查，或是資料庫維護者不小心忘記限制好帳號的權限，可能會被有心人士設計出恰當的輸入條件，湊出能逾越一般該有權限所能進行的資料庫指令，這一般被稱作 SQL Injction 攻擊。

PostgreSQL 企業版提供了資料庫端的資料防護機制，SQL/Protect，能夠在資料庫端防止異常的 SQL，例如，對於資料需要受保護的資料表進行資料「全部」撈出來的 SQL SELECT 指令，或是怪怪的條件等等。

SQL/Protect 模組，當我們選定一些資料庫帳戶 User 或是帳戶群組 Group Role（以上兩者，在 PostgreSQL 裡面統稱為 Role ~）之後，能提供以下的功能：

• 被動紀錄、警示列管帳戶執行可疑活動
• 主動防止列管帳戶執行可疑活動

而「可疑活動」的界定，則是透過學習模式，預先將該帳號會進行的行為全部演練一次。例如，該帳號會對哪幾個表格輸入/查詢，查詢用到的 SQL 有哪一些型態，等等，全部都預先在 SQL/Protect 學習模式下跑一遍。建立起該帳號的行為比對模式（能存取的表格，能進行的作業，等等）。

學習完之後，只要該帳號發生紀錄過的行為模式「以外」，就會觸發 SQL/Protect 功能。因此這個工具的使用場景，便是針對提供 Application Server 使用帳號進行保護：這類帳號的行為固定，都是由已經開發好的程式進行活動；發生了一般模式之外的行徑，八成是被攻擊，就會受 SQL/Protect 所保護。

以下便紀錄基本的使用筆記：

Postgres 的 UNLOGGED Table 功能

PostgreSQL 資料庫會對交易活動產生 Write-Ahead Log Segment，以達成交易資料庫需要的各種要求。不過產生交易紀錄，在某些程度上，也是會佔用作業系統資源。PostgreSQL 提供了針對個別表格設置不要產生交易紀錄，稱作 Unlogged Table，這麼一來便可以在犧牲資料回復保障的狀況下，加速該表格的讀寫。

在 psql 指令界面下使用變數

作 PostgreSQL 功能驗證時，可能會需要設定臨時的變數使用。那麼在 psql 界面下要怎麼宣告變數？

把 Pro*C 移到 EDB 9.5 企業版執行 — ECPGPlus 操作筆記

ECPG 是 Postgres 提供的 C 的開發輔助函式庫，提供所謂 Embedded SQL in C 的功能，類似 Oracle Pro*C 一樣的功能。兩者在使用上提供的 API 差異並不大，比較顯著的差別就在所使用的 SQL 指令，Postgres ECPG 和 Oracle Pro*C 步太能直接通用。

EnterpriseDB 則基於 Postgres ECPG 進一步提供移轉 Oracle Pro*C 到 Postgres 的額外功能，叫做 ECPGPlus。ECPGPlus 針對 EnterpriseDB 提供的企業版資料庫所具備的 Oracle 相容特性，提供相對應的 Embedded SQL in C 轉換，以便以最大幅度直接相容 Oracle Pro*C 的程式碼，達到系統移轉時降低改動幅度的目的。

以下自 EDB 的 PostgreSQL 企業版編譯一個 Oracle 的 Pro*C 程式碼，示範 ECPGPlus 的使用。

Logical Replication Slot on PostgreSQL 9.4 觀察 WAL 交易

這是在 PostgreSQL 9.4 推出的功能，稱作 Logical Decoding。也就是解析交易日誌的功能。發展此功能的目標是為了達成 Log-Based Replication 的功能，以便於日後達成 Master-Master Replication 或是負荷比較小的 Row­level Filtering Replication。直到 2016 年底，該功能還在發展當中（稱作 Bi-Directional replication，BDR）。不過這個功能的推出，也使的些許基於 PostgreSQL 的 Active-Active 實作方案推出，像是 EnterpriseDB 的 EDB Replication Server 的 Multi-Master Replication，或是社群的 pglogical 專案。

Logical Decoding 的使用，也是透過 Replication Slot 來進行，只是這裡的 Replication Slot 不同於在 Streaming Replication 使用的 (Physical) Replication Slot，而是另一類型，叫做 Logical Replication Slot。

以下用 9.4 版的 PostgreSQL作簡易的示範。看看 Logical Decoding 的功能。

pgBouncer 簡介

PostgreSQL 對於一個連線的 Session，就是一個 postgres 程序，會開一個 Unix Socket 來進行。所以若是頻繁的斷線/連線，對 PostgreSQL 來說，開銷比較大。

這也使的 PostgreSQL 一直到 9.5 版為止，對於一個處在 Idle 狀態的 Session，沒有自動逾時斷線的機制，除非手動踢掉它。直到 9.6 版，才多設計一個預設不啟用 Transaction Timeout 的參數，idle_in_transaction_session_timeout，才比較「接近」逾時中止交易的機制。這些都算是傾向保留住 Session 的設計。

（註 1：嚴格來說，idle_in_transaction_session_timeout 這個參數不是逾時斷線，而是交易卡住強制中斷）

（註 2：idle_in_transaction_session_timeout 參數可以針對 Database 或 User 進行個別設置。）

因此對於短暫交易的活動型態，在 PostgreSQL 中，便會採用 Connection Pooling 程式，咬住一些 PostgreSQL 的 Session，然後負責應付外部連線，由它進行分配。

目前 Postgres 的 Connection Pooling 中介程式的專案，以 pgBouncer 與 pgPool-2 為主流。前一陣子的維護活動比較歇緩，不過兩者都正常維護中。

上述兩者都能作為中介的連線管理程式，那兩者有哪些不同？