Swiss PGDay 2026 延续了一个有趣的传统：名字叫 PGDay，实际是两天、双 Track 的 PostgreSQL 活动。它不只是听报告的会议，更像一次 PostgreSQL 工程师、用户、顾问和组织者的年度现场同步。Laurenz Albe 的记录里，技术话题、社区关系、走廊交流和晚间活动交织在一起，正好说明 PostgreSQL 为什么能长期健康增长。
一个会议名字，装下两天内容
Swiss PGDay 仍然在 Rapperswil 的应用科学大学校园举办。按传统，它叫 PGDay；按实际规模，它已经是两天会议，而且有两条演讲线并行。
这类活动对开发者的价值，不只在议程表上。正式 Talk 提供结构化输入，比如行锁、Linux OOM killer、容器内存管理；走廊里的 Hall Track 则负责那些更难写进幻灯片的问题：迁移经验、供应商选择、Oracle 与 PostgreSQL 的现实差异、欧洲市场里的数据库策略。
对 PostgreSQL 这种成熟开源项目来说，会议不是营销附件，而是项目基础设施的一部分。代码贡献者当然重要，但组织者同样重要：他们把人聚到同一个空间里，让开发者愿意继续参与、继续提问、继续贡献。
技术议题：从行锁到容器 OOM
作者自己的演讲主题是 PostgreSQL row locks。行锁是数据库工程里最容易被低估的部分之一：应用代码里看起来只是一次 UPDATE，线上却可能变成等待、超时、死锁，甚至拖垮请求队列。
第一天最吸引作者的报告，是关于在容器化环境中对抗 Linux out-of-memory killer，并结合自定义内存分配器解释 Linux 内存管理。这个主题很现实：数据库跑进容器以后，问题不再只是 PostgreSQL 参数怎么调，还包括 cgroup 限制、内核内存回收、OOM killer 判定，以及应用 allocator 的行为。
会议还首次尝试 Birds of a Feather 形式的 unconference session，也就是开放讨论。这个安排对数据库社区尤其有价值，因为很多问题没有标准答案：高并发下怎么设 lock_timeout，容器里怎么设 memory limit，什么时候该把会话池换成事务池，哪些指标能提前暴露内存风险。这些问题需要不同公司、不同负载的人互相校准。
可以这样实践：本地复现一次 PostgreSQL 行锁等待
如果你读到 row locks 这个主题，最好的学习方式不是背概念，而是亲手制造一次锁等待。下面这个脚本会启动一个 PostgreSQL 容器，让第一个事务持有某一行的锁，再让第二个事务尝试更新同一行并触发 lock_timeout。
运行前需要本机安装 Docker。端口 55432 可按需修改。
docker rm -f swiss-pgday-demo >/dev/null 2>&1 || true
docker run --name swiss-pgday-demo \
-e POSTGRES_PASSWORD=postgres \
-p 55432:5432 \
-d postgres:16
sleep 5
docker exec -i swiss-pgday-demo psql -U postgres <<'SQL'
CREATE TABLE IF NOT EXISTS accounts (
id bigint PRIMARY KEY,
balance integer NOT NULL
);
INSERT INTO accounts (id, balance)
VALUES (1, 100)
ON CONFLICT (id) DO UPDATE SET balance = EXCLUDED.balance;
SQL
# 事务 A：更新 id=1，并通过 pg_sleep 持有行锁 15 秒。
docker exec -i swiss-pgday-demo psql -U postgres <<'SQL' &
BEGIN;
UPDATE accounts SET balance = balance + 10 WHERE id = 1;
SELECT pg_sleep(15);
COMMIT;
SQL
sleep 2
# 事务 B：尝试更新同一行。它会等待事务 A 的行锁，并在 3 秒后超时。
docker exec -i swiss-pgday-demo psql -U postgres <<'SQL'
SET lock_timeout = '3s';
UPDATE accounts SET balance = balance - 5 WHERE id = 1;
SQL
你应该能看到类似下面的错误：
ERROR: canceling statement due to lock timeout
CONTEXT: while updating tuple ... in relation accounts
这个小实验可以改造成团队内部的排障演练：
- 把 lock_timeout 调成 100ms、1s、5s，观察应用侧错误表现。
- 在另一个终端执行
SELECT * FROM pg_locks;，查看等待关系。 - 把 UPDATE 换成
SELECT ... FOR UPDATE，验证读路径也可能参与锁竞争。 - 在业务代码里显式记录 SQL、事务耗时、锁等待错误，避免线上只看到请求超时。
容器里的数据库：别只看 PostgreSQL 参数
会议中关于 Linux OOM killer 的报告提醒了一个常见盲点：数据库进容器后，内存不是单纯由 shared_buffers、work_mem、maintenance_work_mem 决定。容器 memory limit、内核 page cache、并发连接数、排序和 Hash 操作都会影响最终结果。
可以这样实践，把内存边界写进部署配置，而不是只写在文档里：
apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres-lab
spec:
replicas: 1
selector:
matchLabels:
app: postgres-lab
template:
metadata:
labels:
app: postgres-lab
spec:
containers:
- name: postgres
image: postgres:16
env:
- name: POSTGRES_PASSWORD
value: postgres
resources:
requests:
memory: 1Gi
cpu: 500m
limits:
memory: 2Gi
cpu: 1
这不是生产推荐配置，只是一个可改造的起点。真正落地时，还要结合连接池、查询模式、监控指标和压测结果。尤其要注意：把 limit 设得过紧，数据库可能不是变慢，而是被 OOM killer 直接终止。
社区不是配角，是 PostgreSQL 的运行时
作者在文章里反复提到晚餐、社交活动、湖边、Lightning Talks、Hall Track，以及那些每年见一次的人。这些细节看似不技术，却解释了 PostgreSQL 社区的生命力。
开源项目不能只靠商业利益运转。商业公司会竞争，但工程师仍然可以在同一个社区里交换经验。组织者搭建了这种低摩擦交流环境，让新参与者被吸引进来，让老参与者愿意继续回来。
对团队来说，参加这类会议可以有一个更实际的清单：
- 带着一个线上真实问题去，而不是只听热门标题。
- 至少参加一场开放讨论，听不同公司的失败案例。
- 把一个 Talk 转成内部实验，比如行锁复现、OOM 压测、连接池对比。
- 记录联系人和上下文，会议价值常常在三个月后的排障里兑现。
- 不要只派管理者，也要派真正处理数据库问题的一线工程师。
Swiss PGDay 2026 的启发很直接：PostgreSQL 的强大不只来自内核代码，也来自能把严肃技术、开放讨论和长期信任放在同一张桌上的社区。对开发者而言，这样的会议值得关注，因为它给你的不是抽象愿景，而是下一次线上事故前就能用起来的判断力。