Yandex 对以下数据库的贡献将受到审查。
- 点击之家
- 奥德赛
- 恢复到某个时间点 (WAL-G)
- PostgreSQL（包括 logerrors、Amcheck、heapcheck）
- 青梅
视频：
你好世界！ 我叫安德烈·鲍罗丁。 我在 Yandex.Cloud 所做的工作是为了 Yandex.Cloud 和 Yandex.Cloud 客户的利益开发开放关系数据库。
在本次演讲中，我们将讨论大规模开放数据库面临的挑战。 它为什么如此重要？ 因为很小很小的问题，就像蚊子一样，然后就会变成大象。 当你有很多集群时它们就会变大。
但这不是主要的事情。 不可思议的事情发生了。 百万分之一的情况下发生的事情。 在云环境中，您必须为此做好准备，因为当某些事物大规模存在时，令人难以置信的事情就变得很有可能发生。
但！ 开放数据库有什么好处？ 事实上，理论上你有机会处理任何问题。 你有源代码，你有编程知识。 我们把它结合起来，它就起作用了。
开发开源软件有哪些方法？
- 最直接的方法是使用软件。 如果您使用协议，如果您使用标准，如果您使用格式，如果您在开源软件中编写查询，那么您已经支持它。
- 你正在使其生态系统变得更大。 您可以提高早期发现错误的可能性。 您可以提高该系统的可靠性。 您可以增加市场上开发人员的可用性。 你改进这个软件。 如果你只是做出了风格并在那里修改了一些东西，那么你已经是一个贡献者了。
- 另一种可以理解的方法是赞助开源软件。 例如，著名的谷歌编程之夏计划，谷歌向来自世界各地的大量学生支付了可以理解的资金，以便他们开发满足某些许可要求的开放软件项目。
- 这是一种非常有趣的方法，因为它允许软件在不将焦点从社区转移的情况下不断发展。 谷歌作为科技巨头，并没有说我们想要这个功能，我们想要修复这个bug，这就是我们需要挖掘的地方。 谷歌说：“做你该做的事。 只要继续按照你一直以来的方式工作，一切都会好起来的。”
- 参与开源的下一个方法是参与。 当你在开源软件中遇到问题并且有开发人员时，你的开发人员就开始解决问题。 它们开始使您的基础设施更加高效，您的程序更快、更可靠。
开源软件领域最著名的 Yandex 项目之一是 ClickHouse。 这是一个数据库，是为了应对 Yandex.Metrica 面临的挑战而诞生的。
作为一个数据库，它是开源的，目的是创建一个生态系统并与其他开发人员（不仅在 Yandex 内部）一起开发。 现在这是一个大项目，许多不同的公司都参与其中。
在 Yandex.Cloud 中，我们在 Yandex 对象存储（即云存储之上）创建了 ClickHouse。
为什么这在云中很重要？ 因为任何数据库都在这个三角形、这个金字塔、这个内存类型的层次结构中工作。 你有快速但小寄存器和便宜的大但慢的 SSD、硬盘和一些其他块设备。 如果您在金字塔顶端的效率很高，那么您就拥有一个快速的数据库。 如果您在金字塔底部的效率很高，那么您就拥有了一个可扩展的数据库。 在这方面，从下面添加另一层是提高数据库可扩展性的逻辑方法。
怎么可能呢？ 这是本报告的一个重要观点。
- 我们可以通过 MDS 实现 ClickHouse。 MDS 是 Yandex 内部云存储接口。 它比常见的S3协议更复杂，但更适合块设备。 更适合记录数据。 它需要更多的编程。 程序员会编程，这还不错，还很有趣。
- S3 是一种更常见的方法，它使界面更简单，但代价是对某些类型的工作负载的适应较少。
当然，为了向整个 ClickHouse 生态系统提供功能并完成 Yandex.Cloud 内部所需的任务，我们决定确保整个 ClickHouse 社区都能从中受益。 我们通过 S3 实现了 ClickHouse，而不是通过 MDS 实现了 ClickHouse。 这是一项繁重的工作。
参考文献：
“文件系统抽象层”
“AWS SDK S3 集成”
“S3 的 IDisk 接口的基本实现”
“日志存储引擎与 IDisk 接口的集成”
“对 S3 和 SeekableReadBuffer 的日志引擎支持”
“存储条带日志 S3 支持”
“Storage MergeTree 对 S3 的初步支持”
“MergeTree 完全支持 S3”
“支持 S3 上的 ReplicatedMergeTree”
“为 s3 存储添加默认凭据和自定义标头”
“具有动态代理配置的 S3”
“带有代理解析器的 S3”
这是一个用于在 ClickHouse 中实现虚拟文件系统的拉取请求列表。 这是大量的拉取请求。
参考文献：
《DiskS3硬链接优化实现》
“S3 HTTP 客户端 — 避免将响应流复制到内存中”
“避免将整个响应流复制到 S3 HTTP 内存中
客户”
“能够为 S3 磁盘缓存标记和索引文件”
“并行地将部分从 DiskLocal 移动到 DiskS3”
但工作并没有就此结束。 该功能完成后，还需要做一些工作来优化该功能。
参考文献：
“添加 SelectedRows 和 SelectedBytes 事件”
“将 S3 请求中的分析事件添加到 system.events”
“添加 QueryTimeMicroSeconds、SelectQueryTimeMicroSeconds 和 InsertQueryTimeMicroSeconds”
然后有必要使其可诊断、设置监控并使其易于管理。
而这一切都是为了让整个社区、整个ClickHouse生态系统都收到这项工作的成果。
让我们继续讨论事务数据库、OLTP 数据库，这些数据库与我个人更接近。
这是开源DBMS 开发部门。 这些人正在施展街头魔法来改进事务性开放数据库。
其中一个项目是 Postgres 中的连接池，我们可以通过一个示例来讨论我们的工作方式和内容。
Postgres 是一个进程数据库。 这意味着数据库应该具有尽可能少的处理事务的网络连接。
另一方面，在云环境中，典型的情况是一千个连接同时到达一个集群。 而连接池器的任务就是将一千个连接打包成少量的服务器连接。
我们可以说连接池程序是重新排列字节以便它们有效地到达数据库的电话接线员。
不幸的是，连接池没有一个好的俄语单词。 有时它被称为多路复用器连接。 如果您知道如何称呼连接池，那么请务必告诉我，我将非常乐意说正确的俄语技术语言。
我们研究了适合托管 postgres 集群的连接池。 PgBouncer 是我们的最佳选择。 但我们在使用 PgBouncer 时遇到了一些问题。 许多年前，Volodya Borodin 报告说我们使用 PgBouncer，我们喜欢一切，但也有细微差别，还有一些需要改进的地方。
我们工作了。 我们解决了遇到的问题，修补了 Bouncer，并尝试将拉取请求推送到上游。 但基本的单线程很难使用。
我们必须从打过补丁的保镖中收集级联。 当我们有很多单线程 Bouncer 时，顶层的连接会转移到 Bouncer 的内层。 这是一个管理不善的系统，难以构建和扩展。
我们得出的结论是，我们创建了自己的连接池，称为 Odyssey。 我们从头开始编写它。
2019 年，在 PgCon 会议上，我向开发者社区展示了这个池化器。 现在我们在 GitHub 上的 star 数已经不到 2 了，也就是说这个项目还活着，这个项目很受欢迎。
如果您在 Yandex.Cloud 中创建 Postgres 集群，那么它将是一个内置 Odyssey 的集群，在来回扩展集群时会重新配置。
我们从这个项目中学到了什么？ 启动竞争项目始终是一种激进的步骤，当我们说有些问题没有得到足够快的解决，没有在适合我们的时间间隔内得到解决时，这是一种极端的措施。 但这是一个有效的措施。
PgBouncer 开始发展得更快。
现在其他项目也出现了。 例如，pgagroal，它是由 Red Hat 开发人员开发的。 他们追求相似的目标并实现相似的想法，但是，当然，他们有自己的具体细节，更接近 pgagroal 开发人员。
与 postgres 社区合作的另一个案例是恢复到某个时间点。 这是故障后的恢复，这是从备份中恢复。
备份有很多，而且都不同。 几乎每个 Postgres 供应商都有自己的备份解决方案。
如果你拿所有的备份系统，创建一个特征矩阵，并开玩笑地计算这个矩阵中的行列式，它将为零。 这是什么意思？ 如果您获取一个特定的备份文件，那么它无法由所有其他文件的片段组合而成，该怎么办？ 它的实施是独特的，其目的是独特的，其所蕴含的想法是独特的。 而且它们都是具体的。
当我们致力于解决这个问题时，CitusData 启动了 WAL-G 项目。 这是一个着眼于云环境而设计的备份系统。 现在 CitusData 已经成为 Microsoft 的一部分。 在那一刻，我们真的很喜欢 WAL-G 最初版本中提出的想法。 我们开始为这个项目做出贡献。
现在这个项目有几十个开发者，但 WAL-G 的前 10 名贡献者包括 6 个 Yandexoid。 我们在那里带来了很多想法。 当然，我们自己实现它们，自己测试它们，自己将它们投入生产，我们自己使用它们，我们自己弄清楚下一步该往哪里走，同时与大型 WAL-G 社区互动。
从我们的角度来看，现在这个备份系统，包括考虑到我们的努力，已经成为云环境的最佳选择。 这是在云中备份 Postgres 的最佳成本。
这是什么意思？ 我们正在推广一个相当大的想法：备份应该安全、操作成本低并且恢复速度尽可能快。
为什么运营成本应该便宜？ 当没有任何损坏时，您不应该知道自己有备份。 一切正常，您浪费尽可能少的 CPU，使用尽可能少的磁盘资源，并向网络发送尽可能少的字节，以免干扰有价值的服务的有效负载。
当一切都崩溃时，例如，管理员删除了数据，出了问题，你迫切需要回到过去，你用所有的钱来恢复，因为你希望你的数据快速完整地恢复。
我们推广了这个简单的想法。 而且，在我们看来，我们成功地实现了它。
但这还不是全部。 我们还想要一件小事。 我们需要许多不同的数据库。 并非我们所有的客户都使用 Postgres。 有些人使用 MySQL、MongoDB。 在社区中，其他开发者也支持了 FoundationDB。 而且这个名单还在不断扩大。
社区喜欢数据库在云中的托管环境中运行的想法。 而开发者维护他们的数据库，可以通过我们的备份系统与Postgres一起统一备份。
我们从这个故事中学到了什么？ 作为开发部门，我们的产品不是代码行，不是语句，不是文件。 我们的产品不是拉取请求。 这些是我们向社区传达的想法。 这是技术专业知识和技术向云环境的发展。
有Postgres这样的数据库。 我最喜欢 Postgres 核心。 我花了很多时间与社区一起开发 Postgres 核心。
但这里必须指出的是，Yandex.Cloud 内部安装了托管数据库。 很久以前，Yandex.Mail 就开始这么做了。 现在导致托管 Postgres 的专业知识是在邮件想要迁移到 Postgres 时积累的。
邮件与云的要求非常相似。 它需要您能够在数据的任何点实现意外的指数增长。 而且邮件已经负载了数亿个邮箱，其中有大量用户不断发出许多请求。
这对于开发 Postgres 的团队来说是一个相当严峻的挑战。 当时，我们遇到的任何问题都会向社区报告。 这些问题得到了纠正，并且在某些地方被社区纠正了，甚至达到了对其他一些数据库的付费支持甚至更好的程度。 也就是说，您可以向 PgSQL 黑客发送一封信，并在 40 分钟内收到回复。 某些数据库中的付费支持可能会认为有比您的错误更优先的事情。
现在 Postgres 的内部安装有一些 PB 的数据。 每秒有数百万个请求。 这是数千个簇。 规模非常大。
但有一个细微差别。 它并不依赖于精美的网络驱动器，而是依赖于相当简单的硬件。 并且有专门针对有趣的新事物的测试环境。
在测试环境中的某个时刻，我们收到一条消息，表明数据库索引的内部不变量被违反。
不变量是我们期望始终保持的某种关系。
对我们来说，情况非常危急。 这表明某些数据可能已丢失。 数据丢失绝对是灾难性的。
我们在托管数据库中遵循的总体想法是，即使付出努力，也很难丢失数据。 即使你故意删除它们，你仍然需要在很长一段时间内忽略它们的缺失。 数据安全是我们孜孜以求的信仰。
这里出现的情况表明我们可能没有做好准备。 我们开始为这种情况做准备。
我们做的第一件事就是掩埋这数千个集群的日志。 我们发现哪些集群所在的磁盘上存在有问题的固件，导致数据页更新丢失。 标记了所有 Postgres 数据代码。 我们用旨在检测数据损坏的代码标记了那些表明违反内部不变量的消息。
这个补丁实际上没有经过太多讨论就被社区接受了，因为在每个特定的情况下，很明显发生了一些不好的事情并且需要报告到日志中。
之后，我们就开始监控扫描日志了。 如果有可疑信息，他会叫醒值班人员，然后值班人员进行修复。
但！ 扫描日志在一个集群上是一项廉价的操作，但对于一千个集群来说却是灾难性的昂贵操作。
我们写了一个扩展名为 。 它创建了一个数据库视图，您可以在其中廉价且快速地选择有关过去错误的统计信息。 如果我们需要唤醒值班人员，那么我们无需扫描千兆字节的文件，而是通过从哈希表中提取几个字节来找出这一点。
例如，此扩展已在存储库中采用 。 如果你想使用它，你可以自己安装。 当然它是开源的。
但这还不是全部。 我们开始使用 Amcheck（一个社区构建的扩展）来查找索引中的不变违规。
我们发现，如果大规模操作，就会出现错误。 我们开始修复它们。 我们的更正已被接受。
我们发现此扩展无法分析 GiST 和 GIT 索引。 我们让他们支持。 但社区仍在讨论这种支持，因为这是一个相对较新的功能，并且有很多细节。
我们还发现，在检查复制领导者、主服务器上的索引是否违规时，一切正常，但在副本、追随者上，搜索损坏并不那么有效。 并非所有不变量都会被检查。 有一个不变量让我们非常困扰。 为了启用对副本的检查，我们花了一年半的时间与社区沟通。
我们编写的代码应该遵循所有可以...协议。 我们与来自 Crunchy Data 的 Peter Gaghan 讨论了这个补丁很长一段时间。 他必须稍微修改 Postgres 中现有的 B 树才能接受此补丁。 他被接受了。 现在检查副本上的索引也变得足够有效，可以检测我们遇到的违规行为。 也就是说，这些违规可能是由磁盘固件错误、Postgres 中的错误、Linux 内核中的错误以及硬件问题引起的。 我们正在准备的问题来源的清单相当广泛。
但除了索引之外，还有堆这样的部分，即存储数据的地方。 而且可以检查的不变量并不多。
我们有一个名为 Heapcheck 的扩展。 我们开始开发它。 与此同时，EnterpriseDB公司也和我们一起开始编写一个模块，他们以同样的方式将其称为Heapcheck。 只是我们称之为 PgHeapcheck，而他们只是称之为 Heapcheck。 他们的功能相似，签名略有不同，但想法相同。 他们在某些地方实施得更好一些。 他们之前将其发布在开源中。
而现在我们正在发展他们的扩张，因为这不再是他们的扩张，而是社区的扩张。 并且在未来，这是内核的一部分，将提供给大家，以便他们可以提前了解未来的问题。
在一些地方，我们甚至得出结论，我们的监控系统存在误报。 例如1C系统。 使用数据库时，Postgres有时会向其中写入它可以读取的数据，但pg_dump无法读取。
对于我们的问题检测系统来说，这种情况看起来像是腐败。 值班人员被吵醒了。 值班人员看着发生了什么事。 过了一段时间，一个客户过来告诉我有问题。 服务员解释了问题所在。 但问题出在 Postgres 核心。
我找到了关于此功能的讨论。 他写道，我们遇到了这个功能，这令人不愉快，一个人在晚上醒来才能弄清楚它是什么。
社区回应道：“哦，我们真的需要解决这个问题。”
我有一个简单的比喻。 如果你穿着里面有沙粒的鞋子走路，那么原则上你可以继续前进——没问题。 如果你把靴子卖给成千上万的人，那么我们就制作完全不用沙子的靴子。 如果你的鞋子的一位用户要跑马拉松，那么你想要制造非常好的鞋子，然后将其扩展到所有用户。 而这样的意外用户总是在云环境中。 总有用户以某种原始的方式利用集群。 你必须时刻为此做好准备。
我们在这里学到了什么？ 我们学到了一件简单的事情：最重要的是向社区解释存在问题。 如果社区已经认识到这个问题，那么就会出现解决问题的自然竞争。 因为每个人都想解决一个重要的问题。 所有厂商、所有黑客都明白，他们自己也能踩到这个耙子，所以他们想要消灭他们。
如果你正在解决一个问题，但除了你之外没有人困扰，但你系统地解决它并且最终被认为是一个问题，那么你的 Pull request 肯定会被接受。 您的补丁将被接受，您的改进甚至改进请求将由社区审核。 最终，我们让数据库对彼此来说变得更好。
Greenplum 是一个有趣的数据库。 它是一个基于Postgres代码库的高度并行数据库，我非常熟悉。
Greenplum 有有趣的功能 - 附加优化表。 您可以快速添加这些表。 它们可以是柱状或行状。
但是没有集群，即没有可以根据索引之一中的顺序排列表中数据的功能。
出租车上的人走过来对我说：“Andrey，你知道 Postgres。 这里几乎是一样的。 切换到20分钟。 你接受它并去做。” 我想是的，我知道 Postgres，切换 20 分钟 - 我需要这样做。
但不，这不是 20 分钟，而是我花了几个月的时间写的。 在 PgConf.Russia 会议上，我联系 Pivotal 的 Heikki Linakangas 并问道：“这有什么问题吗？ 为什么没有追加优化的表集群？” 他说：“你获取数据。 你排序，你重新排列。 这只是一份工作。” 我：“哦，是的，你只需要接受并去做就可以了。” 他说：“是的，我们需要腾出双手来做这件事。” 我想我绝对需要这样做。
几个月后，我提交了一个实现此功能的拉取请求。 此拉取请求由 Pivotal 与社区一起审核。 当然，也有错误。
但最有趣的是，当这个 pull request 被合并时，Greenplum 本身就发现了 bug。 我们发现堆表在集群时有时会破坏事务性。 这是一个需要解决的问题。 而她就在我刚才碰过的地方。 我的自然反应是——好吧，让我也这样做吧。
我修复了这个错误。 向修复者发送了拉取请求。 他被杀死了。
后来发现这个功能需要在 PostgreSQL 12 的 Greenplum 版本中获得。也就是说，20 分钟的冒险继续着新的有趣的冒险。 接触当前的开发是很有趣的，社区正在削减新的和最重要的功能。 它被冻结了。
但事情并没有就此结束。 毕竟，我们需要为这一切编写文档。
我开始写文档。 幸运的是，Pivotal 的纪录片制片人出现了。 英语是他们的母语。 他们帮助我处理文档。 事实上，他们自己将我的建议改写成了真正的英语。
到这里，冒险似乎就结束了。 你知道当时发生了什么吗？ 出租车上的人过来对我说：“还有两次冒险，每次10分钟。” 我应该告诉他们什么？ 我说现在我会做一个规模报告，然后我们会看到你的冒险经历，因为这是一项有趣的工作。
我们从这个案例中学到了什么？ 因为与开源合作总是与特定的人合作，所以总是与社区合作。 因为在每个阶段我都会与一些开发人员、一些测试人员、一些黑客、一些纪录片制作人、一些架构师一起工作。 我没有与 Greenplum 合作，我与 Greenplum 周围的人一起工作。
但！ 还有一点很重要——这只是工作。 也就是说，你来，喝咖啡，写代码。 各种简单的不变量都有效。 正常地做——会没事的！ 这是一项非常有趣的工作。 Yandex.Cloud 客户（Yandex 内部和外部的集群用户）提出了这项工作的请求。 而且我认为我们参与的项目数量将会增加，参与的深度也会增加。
就这样。 让我们继续讨论问题。
提问环节
你好！ 我们还有另一个问答环节。 在安德烈·鲍罗丁工作室。 这是刚才给大家介绍Yandex.Cloud和Yandex对开源的贡献的人。 我们现在的报告并不完全是关于云的，但同时我们也是基于这样的技术。 如果没有您在 Yandex 中所做的事情，Yandex.Cloud 中就不会有服务，所以我个人感谢您。 广播中的第一个问题是：“你提到的每个项目都写了什么？”
WAL-G中的备份系统是用Go编写的。 这是我们开展的较新项目之一。 他实际上只有3岁。 数据库通常与可靠性有关。 这意味着这些数据库相当古老，并且通常是用 C 语言编写的。Postgres 项目大约开始于 30 年前。 那么C89就是正确的选择。 上面写着Postgres。 更现代的数据库（例如 ClickHouse）通常是用 C++ 编写的。 所有系统开发均基于 C 和 C++。
我们负责 Cloud 费用的财务经理提出了一个问题：“为什么 Cloud 花钱支持开源？”
这里给财务经理一个简单的答案。 我们这样做是为了让我们的服务变得更好。 我们可以在哪些方面做得更好？ 我们可以更高效、更快地做事，并使事情更具可扩展性。 但对我们来说，这个故事主要是关于可靠性。 例如，在备份系统中，我们会 100% 审查适用于该系统的补丁。 我们知道代码是什么。 我们更愿意将新版本投入生产。 也就是说，首先是关于信心、关于发展准备和关于可靠性
另一个问题：“居住在 Yandex.Cloud 中的外部用户的要求与居住在内部云中的内部用户的要求是否不同？”
当然，负载曲线是不同的。 但从我的部门的角度来看，所有特殊和有趣的案例都是在非标准负载上创建的。 具有想象力的开发人员、做出意想不到的开发人员，在内部和外部都可能被发现。 在这一点上，我们都是大致相同的。 而且，Yandex 数据库操作中唯一重要的功能可能是在 Yandex 内部我们有一个教学。 在某些时候，某些可用区域完全进入阴影状态，尽管如此，所有 Yandex 服务都必须以某种方式继续运行。 这是一个很小的差异。 但它在数据库和网络堆栈的接口方面创造了大量的研究开发。 否则，外部和内部安装会产生相同的功能请求以及类似的提高可靠性和性能的请求。
下一个问题：“您个人对您所做的大部分内容被其他云使用这一事实有何看法？” 我们不会透露具体的名称，但许多在 Yandex.Cloud 中完成的项目都在其他人的云中使用。
这很酷。 首先，这表明我们做了正确的事情。 它会伤害自我。 我们更加确信我们做出了正确的决定。 另一方面，这是希望未来这会给我们带来新的想法，来自第三方用户的新要求。 GitHub 上的大多数问题都是由个体系统管理员、个体 DBA、个体架构师、个体工程师创建的，但有时有系统经验的人会说，在 30% 的某些情况下我们会遇到这个问题，让我们考虑如何解决它。 这是我们最期待的。 我们期待与其他云平台分享经验。
你谈了很多关于马拉松的事情。 我知道你在莫斯科跑过马拉松。 因此？ 超越了 PostgreSQL 的家伙？
不，奥列格·巴图诺夫跑得很快。 他比我早一个小时完成。 总的来说，我对自己取得的进展感到满意。 对我来说，完成任务就是一项成就。 总的来说，postgres 社区中有如此多的跑步者是令人惊讶的。 在我看来，有氧运动和对系统编程的渴望之间存在某种关系。
你是说ClickHouse没有跑步者吗？
我确信他们就在那里。 ClickHouse也是一个数据库。 顺便说一句，奥列格现在给我写信：“我们听完报告后去跑步吗？” 这是一个好主意。
Nikita 广播中的另一个问题：“为什么你自己修复了 Greenplum 中的 bug，而不把它交给后辈？” 确实，目前还不清楚该错误是什么以及在哪个服务中，但它可能意味着您谈到的那个错误。
是的，原则上，它可以给某人。 这只是我刚刚更改的代码。 很自然地立即继续这样做。 原则上，与团队分享专业知识的想法是一个好主意。 我们一定会在我们部门的所有成员之间分担 Greenplum 任务。
既然我们谈论的是青少年，那么这里有一个问题。 该人决定在 Postgres 中创建第一个提交。 他需要做什么才能进行第一次提交？
这是一个有趣的问题：“从哪里开始？” 从内核中的某些东西开始通常是相当困难的。 例如，在 Postgres 中，有一个待办事项列表。 但事实上，这就是他们试图做的事情，但没有成功。 这些都是复杂的事情。 通常你可以在生态系统中找到一些实用程序，一些可以改进的扩展，但很少受到内核开发人员的关注。 因此，那里还有更多的增长点。 在 Google 代码之夏计划中，postgres 社区每年都会提出许多可以解决的不同主题。 我想今年我们有三个学生。 有人甚至在 WAL-G 上撰写了对 Yandex 来说很重要的主题。 在 Greenplum 中，一切都比在 Postgres 社区中更简单，因为 Greenplum 黑客很好地对待拉取请求并立即开始审查。 向 Postgres 发送补丁需要几个月的时间，但 Greenplum 会在一天内过来看看你做了什么。 另外一点就是Greenplum需要解决当前的问题。 Greenplum 的使用并不广泛，所以找到你的问题是相当困难的。 当然，首先我们需要解决问题。
来源： habr.com