Postgres RLS(Row Level Security)의 한계와 운영상의 위험성

RLS는 DB 계층에서 보안 정책을 관리하지만, 애플리케이션 코드와 동기화가 어렵고 정책 누락 시 데이터 노출 위험이 크다.

🔗 원문 보기

Is there a tool for graphing #pgBouncer logs? I have lots of this:

2026-04-23 18:15:13.430 [98417] LOG stats: 47 xacts/s, 47 queries/s, 0 client parses/s, 0 server parses/s, 0 binds/s, in 25464 B/s, out 171116 B/s, xact 277853 us, query 277853 us, wait 45832 us

#PostgreSQL

Today's high-bandwith exercise also showed me that I have pgbouncer logs dating back to 2022-09-29

% head -1 /var/log/pgbouncer/pgbouncer.log
2022-09-29 18:46:57.947 UTC [97970] ERROR To allow TLS connections from clients, client_tls_key_file and client_tls_cert_file must be set.

% wc -l /var/log/pgbouncer/pgbouncer.log
5328700 /var/log/pgbouncer/pgbouncer.log

Of those 5.3 million entries, 3.4 million are telling me that I don't have have connection capacity.

% grep -c 'no more connections allowed' /var/log/pgbouncer/pgbouncer.log
3427769

Let's see the busiest days:

% grep 'no more connections allowed' /var/log/pgbouncer/pgbouncer.log > ~/tmp/bad-connections

First day:

% head -1 ~/tmp/bad-connections
2022-09-30 17:51:29.327 UTC [20497] WARNING C-0x8015bbb10: (nodb)/(nouser)@127.163.0.80:65441 pooler error: no more connections allowed (max_client_conn)

Get a count

% cut -f 1 -w ~/tmp/bad-connections | sort | uniq -c > ~/tmp/bad-connections.day.count

301 bad connection days

% wc -l ~/tmp/bad-connections.day.count
301 /usr/home/dvl/tmp/bad-connections.day.count

my top 30 days:

% sort -rn ~/tmp/bad-connections.day.count | head -30
1252069 2026-04-22
327400 2026-04-21
296789 2024-12-01
140700 2026-04-20
137068 2026-04-19
92760 2026-04-02
80634 2025-01-22
78216 2025-09-11
78094 2025-09-10
74338 2025-10-11
60068 2024-10-10
49015 2023-05-08
47293 2024-03-27
44453 2025-09-19
43206 2022-12-15
40506 2024-02-18
39326 2025-01-21
35266 2022-10-10
29787 2024-01-24
27428 2025-10-10
26158 2025-01-20
24899 2024-06-23
24708 2024-10-09
24589 2024-05-15
23888 2024-04-16
23029 2024-05-31
20053 2024-03-21
19197 2026-01-15
18276 2026-04-10
11908 2024-10-11

#PostgreSQL #FreeBSD #pgbouncer

I'm trying to learn how to parse SANs in C thanks to the source code of curl https://github.com/curl/curl/blob/935e1f9963a12ac1a880df538b23b824d2fea7bb/lib/vtls/openssl.c#L2073

Why? I would like pgBackRest to parse SANs before CN because CNs are deprecated for years and they are optional.

The problem is that no matter how hard I try to learn and write C, I fail.

I tried to implement Proxy Protocol for PGbouncer and PostgreSQL, failed.

I could open an issue, wait for a fix and cross my fingers or pray the gods, but I don't want to overload the project. My issue is not that important. What's important to me is the personal reward of contributing to open source. I want to learn. I want to contribute. I want to be a little part of the movement.

You should ask Claude they say. It will be fun they say. I'm not ready for that. I don't want to bypass everything for one of my side projects. But in the meantime, I'm frustated of failing. This is very tempting I must admit.

#opensource #curl #pgbackrest #pgbouncer #postgresql #ai

Postgres의 높은 메모리 점유율이 오히려 좋은 이유

Postgres는 디스크 I/O를 최소화하기 위해 가용한 RAM을 최대한 활용하여 데이터를 캐싱하도록 설계된 데이터베이스다.

🔗 원문 보기

Как построить отказоустойчивый PostgreSQL-кластер и не промахнуться

В исходниках PostgreSQL встречаются ироничные комментарии, а самый веселый, на мой взгляд, находится в строке прямо перед запуском сервера. Судя по логам Git, это комментарий Тома Лейна, который сообщает: "We are ready to rock and roll", а следующей строкой идёт запуск сервера СУБД. Действительно, когда пытаешься запустить кластер PostgreSQL, порой не покидает ощущение "rock and roll", а потом вдруг кластер не стартует или внезапно переключается на другой узел из-за отступов в YAML-конфиге :). В этой статье разберём ключевые элементы отказоустойчивого кластера и типовые места, где чаще всего допускают ошибки.

https://habr.com/ru/companies/postgrespro/articles/1004040/

#postgresql #dba #кластер #датацентр #pgBackRest #wal #PgBouncer #мониторинг #Patroni #Stolon

Когда стойка умирает, а 5xx остаётся нулевым. Разбор скрытой деградации PostgreSQL

09:12 — db-replica-02 connection timeout HTTP 5xx = 0.2% HAProxy зелёный p50 = 38-42ms Replica в другой стойке недоступна Отказоустойчивость потеряна Инцидент не объявлен Читать разбор

https://habr.com/ru/articles/1002056/

#PostgreSQL #отказоустойчивость #деградация #retry #HAProxy #PgBouncer #ToR #инцидент #latency #SRE

Spent most of the afternoon tuning #Postgresql and bits of #Mastodon

Looked at #PGBouncer, but I don't think I need it (yet)

#MastoAdmin