Braintree Payments uses PostgreSQL as its primary datastore. We rely heavily on the data safety and consistency guarantees a traditional relational database offers us, but these guarantees come with certain operational difficulties. To make things even more interesting, we allow zero scheduled functional downtime for our main payments processing services.

DBA 经常需要排查某一个事务中有哪些 SQL 的场景。典型的 case 就是 DB 有一个 lock 报警，从系统表中查看发现是1个 update 等待的 SQL 是1个 select。熟悉 PostgreSQL 的同学都知道：在 PostgreSQL 中，由于特有的 MVCC 机制，读不阻塞写，写不堵塞读。

那么为什么会产生这种 lock？

实际就是因为这个 select 处于一个事务中，事务中有其他 update/delete 等写入操作持有后面的其他事务中的 update 操作所需要的 lock。此时就需要到 DB log 去排查这个 select 所处的事务的完整的全部 SQL，反馈给业务线的开发同学，以便于进一步优化。

最近有业务线的同学向 DBA 提出这样的需求:“我的表里有很多敏感数据，怎么给使用者(从 DBA 角度来看就是 DB User)指定查看某些特定行或某些列的权限？”

这是我们经常用到的业务场景，比如最典型全公司的短信数据和用户管理平台场景，如何限制各部门仅可查看属于本部门的某些非敏感数据？

PostgreSQL 为了符合各种场景的安全需求，它的权限控制非常完善，它在各个级别上都具有广泛的安全功能。接下来我们来看一下在 PostgreSQL 中利用行级安全和列级安全来解决上述问题。

Everything about database,business.(Most for PostgreSQL). - blog/20170521_01.md at master · digoal/blog