這是 Jespen 第一次測試 PostgreSQL,就順利找出可重製的 bug 了:「PostgreSQL 12.3」。

第一個 bug 是 REPEATABLE READ 下的問題,不過因為 SQL-92 定義不夠嚴謹的關係,其實算不算是 bug 有討論的空間,這點作者 Kyle Kingsbury 在文章裡也有提出來:

Whether PostgreSQL’s repeatable-read behavior is correct therefore depends on one’s interpretation of the standard. It is surprising that a database based on snapshot isolation would reject the strict interpretation chosen by the seminal paper on SI, but on reflection, the behavior is defensible.

另外一個就比較沒問題了,是 SERIALIZABLE 下的 bug,在 SQL-92 下對 SERIALIZABLE 的定義是這樣:

The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.

也就是說,在 SERIALIZABLE 下一堆 transaction 的執行結果,你至少可以找到一組排序,使得這些 transaction 的結果是等價的。

而 Jespen 順利找出了一組 transaction (兩個 transaction),在 SERIALIZABLE 下都成功 (但不應該成功):

對於這兩個 transaction,不論是上面這條先執行,還是下面這條先執行,都不存在等價的結果,所以不符合 SERIALIZABLE 的要求。

另外也找到一個包括三個 transaction 的情況:

把 transaction 依照執行的結果把 dependency 拉出來,就可以看出來裡面產生了 loop,代表不可能在 SERIALIZABLE 下三個都成功。

在 Jespen 找到這些 bug 後,PostgreSQL 方面也找到軟體內產生 bug 的部份,並且修正了:「Avoid update conflict out serialization anomalies.」,看起來是在 PostgreSQL 引入 Serializable Snapshot Isolation (SSI) 的時候就有這個 bug,所以 9.1 以後的版本都有這個問題...

這次順利打下來,測得很漂亮啊... 翻了一下 Jespen 上的記錄,發現好像還沒測過 MySQL,應該會是後續的目標?

SQL-92 裡定義 Isolation Level 的背景

Twitter 上看到這則推,講到在 SQL-92 裡面 Isolation Level 定義的背景:

先是講了為什麼有 SERIALIZABLEREPEATABLE READREAD COMMITTED,然後講為什麼是用 anomalies 定義 (除了 SERIALIZABLE),也因此造成了定義不清楚而導致問題。

SQL-92 的 isolation 問題後來在其他文件裡面有被討論,像是 1995 年的「A Critique of ANSI SQL Isolation Levels」,以及 2000 年的論文「Generalized Isolation Level Definitions」,過了二十年後的現在,大家也都大概知道有哪些雷區了。

另外講到 Isolation Level,實務上會希望知道 database 與標準之間的差異,在「Hermitage: Testing transaction isolation levels」這篇可以看到各家 RDBMS 在不同設定下實際的 isolation level,包括了 open source 的 MySQLPostgreSQL 與商用常遇到的 OracleMicrosoft SQL Server

MySQL 的 REPEATABLE READ 因為 SQL-92 的定義不清楚,所以大概知道這邊本來就有爭議,比較意外的反倒是 Oracle 裡面的 SERIALIZABLE 實際上是 Snapshot Isolation,沒有辦法達到 SQL-92 裡面最高等級的 Isolation Level。


Amazon S3 的 Replication 也給出 SLA 了

Amazon S3 的 cross-region replication 與 same-region replication 也提供 SLA 了:「S3 Replication Update: Replication SLA, Metrics, and Events」。

  • Most of the objects will be replicated within seconds.
  • 99% of the objects will be replicated within 5 minutes.
  • 99.99% of the objects will be replicated within 15 minutes.


When you enable this feature, you benefit from the associated Service Level Agreement. The SLA is expressed in terms of a percentage of objects that are expected to be replicated within 15 minutes, and provides for billing credits if the SLA is not met:

  • 99.9% to 98.0% – 10% credit
  • 98.0% to 95.0% – 25% credit
  • 95% to 0% – 100% credit

不過只保證 99% 的物件在五分鐘內會被 replicate 有點低,應該跟底層的網路 latency 有關?

維基百科的 Vital articles

Hacker News Daily 這邊看到,英文版維基百科有一套列表,整理出「重要」的條目:「Wikipedia:Vital articles」。

目前的列表有五個層級,從 Level 1 到 Level 5,後面的 Level 包含了前面 Level 的文章:

  • Level 1 只有 10 篇。
  • Level 2 有 100 篇 (包含 Level 1 的 10 篇,以下類推)。
  • Level 3 有 1000 篇。
  • Level 4 有 10000 篇。
  • Level 5 有 50000 篇。

看到的第一個問題就是這些列表怎麼產生的,這點在 Wikipedia talk:Vital articles/Frequently Asked Questions 裡面有提到列表的歷史:這是 2004 年由 David Gerard 發起,之後擴大到社群並且分不同等級。而這也說明了這些列表示人工選擇的,而不是透過演算法推薦的:

The English Wikipedia Vital Articles list was originally created in August 2004 by David Gerard as an adaptation of the metawiki List of articles every Wikipedia should have. Since then, the Vital Articles list has undergone numerous revisions by multiple editors, and has expanded to include 5 different levels of vitalness.


A vital article is one considered essential to the subjects listed. For example, it would be difficult to discuss Science without the scientific method, History without World War II, Language without Grammar, Earth science without Geology, or Civics without Democracy. Individuals within the People section represent the pinnacles of their field, such as Albert Einstein in "Inventors and scientists" or William Shakespeare in "Authors". In sections such as those pertaining to People, History or Geography, weight is given to some articles to produce a more diverse, global list.

這些列表其中一種用法是「想要了解某個領域」,但剛剛翻了一下 Level 1 與 Level 2 可以發現似乎太少,看起來 Level 3 的資料算是個還不錯的起點...

RDBMS 裡的各種 Lock 與 Isolation Level

來推薦其他人寫的文章 (雖然是在 Medium 上...):「複習資料庫的 Isolation Level 與圖解五個常見的 Race Conditions」、「對於 MySQL Repeatable Read Isolation 常見的三個誤解」,另外再推薦英文維基百科上的「Snapshot isolation」條目。

兩篇文章都是中文 (另外一個是英文維基百科條目),就不重複講了,這邊主要是拉條目的內容記錄起來,然後寫一些感想...

SQL-92 定義 Isolation 的時候,技術還沒有這麼成熟,所以當時在訂的時候其實是以當時的技術背景設計 Isolation,所以當技術發展起來後,發生了一些 SQL-92 的定義沒那麼好用的情況:

Unfortunately, the ANSI SQL-92 standard was written with a lock-based database in mind, and hence is rather vague when applied to MVCC systems. Berenson et al. wrote a paper in 1995 critiquing the SQL standard, and cited snapshot isolation as an example of an isolation level that did not exhibit the standard anomalies described in the ANSI SQL-92 standard, yet still had anomalous behaviour when compared with serializable transactions.

其中一個就是 Snapshot Isolation,近代的資料庫系統都用這個概念實做,但實際上又有不少差別...

另外「Jepsen: MariaDB Galera Cluster」這篇裡出現的這張也很有用,裡面描述了不同層級之間會發生的問題:

這算是當系統有一點規模時 (i.e. 不太可能使用 SERIALIZABLE 避免這類問題),開發者需要了解的資料庫限制...

2018 年矽谷科技公司的薪資

不太意外的,排名起來加州這一區的科技公司的薪資還是最高的 (這邊包括了所有的所得,包括薪資、股票與分紅):「Top Paying Tech Companies of 2018」。

已經先整理出來的前五名分成「Entry-level / 1+ Yrs of Experience」、「Mid-level / 3+ Yrs of Experience」、「Been Around the Block / 5+ Yrs of Experience」三類,可以看到相對於年資的增加,薪資的調整也很快...


AWS Lambda 也提供 SLA 了

在「AWS Lambda announces service level agreement」這邊看到 AWS Lambda 提供 99.95% 的 SLA :

We have published a service level agreement (SLA) for AWS Lambda. We will use commercially reasonable efforts to make Lambda available with a Monthly Uptime Percentage for each AWS region, during any monthly billing cycle, of at least 99.95% (the “Service Commitment”).

不過這種東西都是宣示意味比較重 (至少表示 AWS 認為產品穩定度夠上 SLA),倒不是希望會用到...

GCP 推出 Cloud HSM (beta)

這算是 Google Cloud Platform 在補產品線,讓那些有強制使用 HSM 的需求的應用 (通常是遇到一定要 FIPS 140-2 的規範) 可以搬上雲端:「Introducing Cloud HSM beta for hardware crypto key security」。

從圖片上可以看到 LiquidSecurity,應該是「LiquidSecurity® General Purpose HSM Adapters and Appliances」這個產品:

如同 AWSCloudHSM 服務,GCP 的 Cloud HSM 也是提供 FIPS 140-2 Level 3:

Cloud HSM allows you to host encryption keys and perform cryptographic operations in FIPS 140-2 Level 3 certified HSMs (shown below).

演算法上,支援 AESRSAECC (NIST 的 P-256 與 P-384):

In addition to symmetric key encryption using AES-256 keys, you can now create various types of asymmetric keys for decryption or signing operations, which means that you can now store your keys used for PKI or code signing in a Google Cloud managed keystore. Specifically, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 keys will be available for signing operations, while RSA 2048, RSA 3072, and RSA 4096 keys will also have the ability to decrypt blocks of data.

目前只支援 us-east1us-west1,另外價錢也比軟體服務版本的 Cloud KMS 貴不少:

Billable itemFor keys with protection level SOFTWAREFor keys with protection level HSM
Active AES-256 and RSA 2048 key versions$0.06 per month$1.00 per month
Active RSA 3072, RSA 4096 or Elliptic Curve key versions$0.06 per month$2.50 per month for the first 2,000
$1.00 per month thereafter
Destroyed key versionsFreeFree
Key operations: Cryptographic$0.03 per 10,000 operations$0.03 per 10,000 operations for AES-256 and RSA 2048 keys
$0.15 per 10,000 operations for RSA 3072, RSA 4096, and Elliptic Curve keys
Key operations: AdminFreeFree

不過一般情況應該不會得用 CloudHSM,先有個印象就好...

Working Set Size (WSS) 的想法

NetflixBrendan Gregg (他比較知名的發明是 Flame Graph) 寫了一篇「How To Measure the Working Set Size on Linux」,他想要量測單位時間內會用到的記憶體區塊大小:

The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

這可以拿來分析這些應用程式是否能夠利用 L1/L2/L3 cache 大幅增加執行速度,於是就可以做成圖,像是這樣:

在 Netflix 這樣人數的公司,需要設計一些有用的指標,另外發展出對應的工具,讓其他人更容易迅速掌握狀況,畢竟不是每個人都有上天下海的能力,遇到狀況可以馬上有頭緒進行 trouble shooting...

Avast 放出他們的 Decompiler,RetDec

AvastMIT License 放出他們的 Decompiler,叫做 RetDec:「Avast open-sources its machine-code decompiler」,專案在 GitHub 上的 avast-tl/retdec 這邊。

Decompiler,也就是直接把 machine code 試著轉回高階語言的程式碼:

這對於分析工作來說簡化很多,尤其是在資安產業的人... 以往比較常見是轉成 assembly 再用人工分析,現在這樣有機會讓大腦輕鬆一些。

雖然目前有些限制 (像是 32 bits only),不過 open source 出來後,可以預料會有不少人開始加功能進去:

  • Supported file formats: ELF, PE, Mach-O, COFF, AR (archive), Intel HEX, and raw machine code.
  • Supported architectures (32b only): Intel x86, ARM, MIPS, PIC32, and PowerPC.