Телеграмм чат группы pgsql страница 10217

autovacuum в postgresql.conf закомментирован
какое у него значение по умолчанию?

16:12пожаловаться #1

YS

Yaroslav Schekin in pgsql – PostgreSQL

так выглядит запрос

UPDATE events SET transactionid=@tids, value3=@val3, comment='_ATZ'||comment WHERE uid=@uid;
UPDATE transactions SET refillid=@rids WHERE uid=ANY(@tids)

И Вы выполняете 45000 таких в одной транзакции? Передавая каждый раз разные @tids и прочие параметры?
Prepared statements используете? Или параметризацию? И сколько там элементов в массивах?
В общем, планы этих запросов Вы пробовали смотреть? Или хотя бы логи, для начала (log_min_duration_statement или сразу log_statement)?

> какое у него значение по умолчанию?

On, естественно. И очень советую не трогать.

16:15пожаловаться #2

LH

Yaroslav Schekin

И Вы выполняете 45000 таких в одной транзакции? Передавая каждый раз разные @tids и прочие параметры?
Prepared statements используете? Или параметризацию? И сколько там элементов в массивах?
В общем, планы этих запросов Вы пробовали смотреть? Или хотя бы логи, для начала (log_min_duration_statement или сразу log_statement)?

> какое у него значение по умолчанию?

On, естественно. И очень советую не трогать.

1.да
2.да
3.не знаю что это
4.-||-
5.в массивах не более 10 элементов
6.не смотрел. использую npgsql (C#), пока не разбирался как это там сделать
7.логи сейчас посмотрю

16:18пожаловаться #3

LH

и еще забыл упомянуть, что параллельно выполняется не менее 30 таких запросов

16:20пожаловаться #4

LH

сейчас сделал последовательную отправку, выполнилось без торможений и гораздо быстрее, хотя начальная скорость параллельной отправки раза в 4 выше

16:21пожаловаться #5

YS

Yaroslav Schekin in pgsql – PostgreSQL

> 3.не знаю что это
Это PREPARE или аналогичная возможность client protocol. Чтобы запрос 45000 раз не парсить и т.п. ;)
Ну а уж хотя бы параметризация должна использоваться всегда (это тоже возможность протокола, и сейчас её поддерживают почти все API).

> 6.не смотрел. использую npgsql (C#), пока не разбирался как это там сделать

А это не надо там делать, к счастью. ;) Т.е. Вы вытащите запросы из логов, а потом посмотрите их план(ы) в другой сессии.
Или можно (так точнее) использовать расширение https://www.postgresql.org/docs/current/static/auto-explain.html

16:22пожаловаться #6

LH

Yaroslav Schekin

> 3.не знаю что это
Это PREPARE или аналогичная возможность client protocol. Чтобы запрос 45000 раз не парсить и т.п. ;)
Ну а уж хотя бы параметризация должна использоваться всегда (это тоже возможность протокола, и сейчас её поддерживают почти все API).

> 6.не смотрел. использую npgsql (C#), пока не разбирался как это там сделать

А это не надо там делать, к счастью. ;) Т.е. Вы вытащите запросы из логов, а потом посмотрите их план(ы) в другой сессии.
Или можно (так точнее) использовать расширение https://www.postgresql.org/docs/current/static/auto-explain.html

щас догнал про параметризацию. да, она используется

16:23пожаловаться #7

YS

Yaroslav Schekin in pgsql – PostgreSQL

и еще забыл упомянуть, что параллельно выполняется не менее 30 таких запросов

Они могут просто блокировать друг друга, например. Можно включить логирование locks (см. log_lock_waits) или просто "ловить" их в pg_locks. ;)

16:24пожаловаться #8

YS

Yaroslav Schekin in pgsql – PostgreSQL

щас догнал про параметризацию. да, она используется

Может, стоило бы посмотреть на prepared statements, всё же? Казалось бы, при таком количестве повторений того же запроса это должно быть выгодно (хотя непосредственно к проблеме это не относится, просто на будущее).

16:25пожаловаться #9

LH

Yaroslav Schekin

Может, стоило бы посмотреть на prepared statements, всё же? Казалось бы, при таком количестве повторений того же запроса это должно быть выгодно (хотя непосредственно к проблеме это не относится, просто на будущее).

как раз читаю про это

16:25пожаловаться #10

LH

спасибо за ответы

16:30пожаловаться #11

YS

Yaroslav Schekin in pgsql – PostgreSQL

сейчас сделал последовательную отправку, выполнилось без торможений и гораздо быстрее, хотя начальная скорость параллельной отправки раза в 4 выше

А это уж тем более похоже на блокировки. Скорее всего, там затрагиваются те же записи (по events.uid или transactions.uid).
Ну а так — что гадать, смотрите логи. ;)

16:34пожаловаться #12

LH

Yaroslav Schekin

А это уж тем более похоже на блокировки. Скорее всего, там затрагиваются те же записи (по events.uid или transactions.uid).
Ну а так — что гадать, смотрите логи. ;)

ок, буду копать. спасибо

16:38пожаловаться #13

S

Slach in pgsql – PostgreSQL

Всем привет, помогите разобраться с правами в postgres?

в /docker-entrypoint.initdb.d/init_schema.sql
стоит вот такое

CREATE USER grafana WITH PASSWORD 'grafana';
CREATE DATABASE grafana;
GRANT ALL PRIVILEGES ON DATABASE grafana TO grafana;

\c grafana

DROP TABLE IF EXISTS test_grafana;
CREATE TABLE IF NOT EXISTS test_grafana(event_time TIMESTAMP, service_name VARCHAR(100), too_big_value FLOAT);

в логах

/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init_schema.sql
CREATE ROLE
CREATE DATABASE
GRANT
You are now connected to database "grafana" as user "postgres".
psql:/docker-entrypoint-initdb.d/init_schema.sql:7: NOTICE:  table "test_grafana" does not exist, skipping
DROP TABLE
CREATE TABLE

таблица создается из под юзера postgres

запускаю docker-compose exec postgres psql -U grafana

grafana=> \c
You are now connected to database "grafana" as user "grafana".
grafana=> SELECT count(*) FROM test_grafana;
ERROR:  permission denied for table test_grafana

ПОЧЕМУ?

17:30пожаловаться #14

R

RTM in pgsql – PostgreSQL

Slach

Всем привет, помогите разобраться с правами в postgres?

в /docker-entrypoint.initdb.d/init_schema.sql
стоит вот такое

CREATE USER grafana WITH PASSWORD 'grafana';
CREATE DATABASE grafana;
GRANT ALL PRIVILEGES ON DATABASE grafana TO grafana;

\c grafana

DROP TABLE IF EXISTS test_grafana;
CREATE TABLE IF NOT EXISTS test_grafana(event_time TIMESTAMP, service_name VARCHAR(100), too_big_value FLOAT);

в логах

/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init_schema.sql
CREATE ROLE
CREATE DATABASE
GRANT
You are now connected to database "grafana" as user "postgres".
psql:/docker-entrypoint-initdb.d/init_schema.sql:7: NOTICE:  table "test_grafana" does not exist, skipping
DROP TABLE
CREATE TABLE

таблица создается из под юзера postgres

запускаю docker-compose exec postgres psql -U grafana

grafana=> \c
You are now connected to database "grafana" as user "grafana".
grafana=> SELECT count(*) FROM test_grafana;
ERROR:  permission denied for table test_grafana

ПОЧЕМУ?

You are now connected to database "grafana" as user "postgres".

17:37пожаловаться #15

S

Slach in pgsql – PostgreSQL

RTM

You are now connected to database "grafana" as user "postgres".

я понимаю, что owner другой...
ALTER DEFAULT PRIVILEGES GRANT ALL ON TABLES TO grafana;
ALTER DEFAULT PRIVILEGES GRANT ALL ON SEQUENCES TO grafana;

вот это помогло
https://dba.stackexchange.com/questions/53914/permission-denied-for-relation-table

17:40пожаловаться #16

R

RTM in pgsql – PostgreSQL

я бы вообще сделал по другому. после create database grafana; alter owner на бд сделал grafana. и дальше уже все пользователем графана бы делал

17:41пожаловаться #17

S

Slach in pgsql – PostgreSQL

RTM

я бы вообще сделал по другому. после create database grafana; alter owner на бд сделал grafana. и дальше уже все пользователем графана бы делал

ALTER TABLE test_grafana OWNER TO grafana;
да. это надежнее спасибо

17:49пожаловаться #18

AB

Anatoly Batura in pgsql – PostgreSQL

Коллеги, всем добра.
Postgres 9.6
Есть некая заковыка с типом данных 'inet'

с IPv4 прекрасно работает заполнение таблицы пулов адресов функцией путем сложения адреса с типом int примерно такой конструкции, код упрощен для понимания.
-------
_ip_start :=’192.168.0.0’;

FOR _ip_inc IN 0..65535
LOOP
_ip_addr := _ip_start + _ip_inc;
INSERT INTO ip_pool_addr (ip_addr ) VALUES ( _ip_addr );
END LOOP;
-------
Но вот с IPv6 это дело не прокатывает. всяко пробовал, но не смог сделать вычисление следующего префикса /56.
Не складываются адрес + инкрементный адрес (inet + inet) , inet + int, inet + bigint
идет ругань от БД

Как вычислить следующий адрес, который на /56 адресов больше предыдущего чтобы запихать его в БД?

17:58пожаловаться #19

T

Tuntsov in pgsql – PostgreSQL

Всем привет. Ребятки, подскажите, я восстановился из бэкапа, нагнал wal’ов на сервак — все отлично. Теперь хочу что он стал слейвом вновь. Какой алгоритм действий должен я совершить для этого? Как я понимаю, recovery.conf написать будет недостаточно?