学习让我快乐

深入浅出 KuiBaDB: Expression

前言 KuiBaDB 的表达式想解决之前在 PostgreSQL 中遇到的表达式相关的几个问题: 最高只支持 8byte 对齐. 之前做过基于 int128 的 decimal128 类型, int128 是 16byte 对齐, 因此编译器在某些场景下会生成一些要求 16byte 对齐, 但效率更高的指令. 但由于 pg 最高只支持 8byte 对齐, 即 decima...

Posted by w@hidva.com on June 12, 2021

深入浅出 KuiBaDB: State

前言 KuiBaDB 最开始的一个主要想法之一, 便是移除掉 PostgreSQL 中肆意泛滥的全局变量. 我个人认为, 全局变量的肆意使用违背了代码应所见即所得的直观性质, 以一个函数为例, 所见即所得意味着我们可以仅根据该函数的签名便可得知该函数可能依赖的状态, 该函数应在哪些上下文下才能调用等. 但在 PG 中, 在使用调用一个函数之前, 我们不得不了解下这个函数自身的实现, 这个函...

Posted by w@hidva.com on May 31, 2021

The KuiBaDB Column Storage

The KuiBaDB Column Storage is heavily inspired by ‘Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processing’ and rocksdb. The first prototype design was completed on October 7, 202...

Posted by w@hidva.com on April 25, 2021

消失的两阶段事务

大年三十, 忽然收到之前搭建的 gp 集群 mirror xlog 堆积的报警, 本来没太当回事, 以为又是想往常一样, 要么是 mirror replay wal 时太慢了, 要么是有个两阶段事务一直没有结束导致. 又忽然想到, 如果是两阶段事务一直没有结束, 那么 primary, mirror 应该要一起 xlog 堆积的. 所以八成是 mirror replay wal 又慢了. 但...

Posted by w@hidva.com on February 14, 2021

Greenplum 从自适应调度到 Concurrency Scaling

自去年提出了 Greenplum 自适应调度的想法, 到最近把这套自适应调度推到我们线上, 这期间也对最初提出的想法又做了一系列加强, 也进一步加深了对 Greenplum 执行框架的理解. 关于 Greenplum 执行框架这里不在做过多介绍, 可以参阅之前的文章. 简单来说, 在优化结束, 执行计划确定了之后, GP 会遍历 plan tree, 之后以 Motion 节点为边界将执行...

Posted by w@hidva.com on January 29, 2021

Drop checker 与 PhantomData

在回家的路上时候, 忽然想到了 PhantomData.. 当时在囫囵吞枣地学习 rust 时对 PhantomData 只是一扫而过, 只是有印象说是, 应该根据语义来决定是否应该加 PhantomData. 比如 Iter 对外看上去就像是 &'a T 的容器, 所以 Iter 在定义上使用了 _marker: marker::PhantomData<&'a T&g...

Posted by w@hidva.com on December 31, 2020

最近遇到的有趣事情

C/C++ strict aliasing rule 之前在做某个项目时, 遇到了一个问题, 细细抽取之后, 得到最小可复现代码, 即如下代码在 gcc O2 时会得到错误的结果. #include <stdlib.h> #include <stdio.h> static inline int64_t GetScaleFromBits(int64_t bits)...

Posted by w@hidva.com on December 23, 2020

不不不这不可能 - data race 造成的诡异现象

最近在忙着为之前做的外表分区增加导出能力的功能, 继之前压测发现的 gp 内核一处内存泄漏之后, 本以为接下来就顺风顺水波澜不惊, 准备开始走评审, 合入, 上线了. 没想到, 又出了一个幺蛾子: (gdb) bt #0 0x00007fac6e2b7277 in raise () from /lib64/libc.so.6 #1 0x00007fac6e2b8968 in ab...

Posted by w@hidva.com on December 23, 2020

内存又泄漏了啊=。=

双 11 例行巡检时忽然发现大盘上某处地方不太对劲, 两周以来, 实例计算节点所占内存一直在缓慢地上升中. 登陆到实例计算节点上 top shift+M 看了下, 两个 postgresql startup process 很诡异地占了很大的内存, 位列 top2. 要知道 startup process 只是反复 redo xlog, redo 完一条 xlog 之后, 这期间所持有内存就...

Posted by w@hidva.com on November 24, 2020

SELECT pg_locks crash 了

TL; DR Greenplum 4.3 pg resqueue lock 链路 ResLockWaitCancel() 访问 LockMethodProcLockHash 这个共享结构时未使用指定的锁, 导致其他并发访问 LockMethodProcLockHash 的会话, 比如 select * from pg_locks, 看到了 LockMethodProcLockHash HA...

Posted by w@hidva.com on October 10, 2020

rust 究竟是怎么模式匹配的

最近用 rust 重写了之前用 go 写的一个锁等待图生成工具, 这个小玩意会读取收集 Greenplum 当前锁信息, 并生成对应的锁等待图, 可用来大幅加速线上问题的排查. 不幸的是, 之前用 go 写出之后, 不小心把源码弄丢了, 导致我们目前只有 binary 能用. 导致了在使用过程中很多想加的小功能都整不了了. 正巧这次借着 rust 的机会重新实现了下这个功能, 此间过程中也加...

Posted by w@hidva.com on September 26, 2020

GP slice 自适应调度

众所周知, 在执行时, gp 会将查询进行分层处理, 每一层也便是一个 slice, slice 之间通过 motion 节点来完成数据交互. 当前 gp 总会将 slice 调度到集群中每一个计算节点上进行运行. 这其实并不是一个最合适的选择. 以如下查询为例, 在一个共有 3 个 primary segment 的集群中生成了如下查询计划. 可以看到, slice1 总共只会吐出 ...

Posted by w@hidva.com on September 21, 2020

从 C++20 标准来看 memory order: 1

接从 C++20 标准来看 memory order:0 在 c++20 标准中, 与 memory order 有关的章节主要集中在 6.9.1 Sequential execution, 6.9.2 Multi-threaded executions and data races, 31.4 Order and consistency 中. 要想精确掌握 memory order, ...

Posted by w@hidva.com on September 15, 2020