Я думаю, что наличие запрашиваемых данных в shared_buffers и/или кеше файловой системы тоже вносит свою лепту.

Ну конечно. Но вы же не будете тестить CPU на непрогретых данных. Чат все же не про аниме

Всем привет. Очень увлекся PostgreSQL и буду рад присоединиться к коммьюнити. Даже для себя начал вести cheat sheet того что изучаю и использую ежедневно. https://github.com/andrewkslv/postgresql-cheat-sheet п.с. буду рад пулл реквестам

а тут что-то кроме pgsql --help и \? внутри самого psql?

а тут что-то кроме pgsql --help и \? внутри самого psql?

Справедливый вопрос. Большинство паттернов которые есть в \? относительно сложно запоминать начинающим разработчикам, в то время когда необходимо внедрять новый функционал. Поэтому набор Z минимальных команд помогают адаптироваться в новой обстановке.

а тут что-то кроме pgsql --help и \? внутри самого psql?

+1

ребята, а в чем может быть дело? создал в графической среде таблицу, одна сущность не отображается, вылетает ERROR 1064 (42000): You have an error in your SQL syntax. в чем может быть причина?

ребята, а в чем может быть дело? создал в графической среде таблицу, одна сущность не отображается, вылетает ERROR 1064 (42000): You have an error in your SQL syntax. в чем может быть причина?

Ошибка синтаксиса, ваш кэп

Ошибка синтаксиса, ваш кэп

так а как ее искать? если я из среды загрузил в базу все

Глазами посмотри

каким образом в таком случае база вообще сформировалась, если сгененированный код содержал синтаксические ошибки?

так а как ее искать? если я из среды загрузил в базу все

"Какие бомбы? В какую цель?" ;) Т.е. что и где конкретно Вы делали (Какая сущность? Из какой среды? Как загрузили?)?

ребята, а в чем может быть дело? создал в графической среде таблицу, одна сущность не отображается, вылетает ERROR 1064 (42000): You have an error in your SQL syntax. в чем может быть причина?

Графическая среда фигню сгенерировала

коллеги, а кто-нибудь видел, чтобы pg_upgrade ломался на системных вьюхах?

обновляю копрокластер с 9.5 до 9.6

# sudo -u postgres $NEWBIN/pg_upgrade -k -b $OLDBIN -B $NEWBIN -d $OLD_DATA -D $NEW_DATA -p $OLD_PORT -P $NEW_PORT Performing Consistency Checks ----------------------------- Checking cluster versions ok ... Performing Upgrade ------------------ Analyzing all rows in the new cluster ok ... Restoring global objects in the new cluster ok Restoring database schemas in the new cluster postgres *failure* Consult the last few lines of "pg_upgrade_dump_12381.log" for the probable cause of the failure. Failure, exiting

pg_upgrade_dump_12381.log - https://gist.github.com/Bregor/80af47d6761abe6aa8632580ab97ccef

то есть оно не смогло обновить системную базу, сломавшись на вьюхе pg_stat_activity

это вообще лечится?..

коллеги, а кто-нибудь видел, чтобы pg_upgrade ломался на системных вьюхах?

А это смотрели? Там правда 9.3 и 9.4, но тоже может быть связано с тем, что у pg_stat_activity появилась новая колонка

Коллеги, я на всякий случай еще разок поинтересуюсь. Никто не билдил plv8 2.1 под винду под 9.6 или 10?

это вообще лечится?..

А разве это (pg_stat_activity) системный view? Он же в схеме postgres_exporter.

День добрый ! есть проблема оперативного характера , не происходит update в одной из крупных таблиц нужна консультация вчера усё работало pg 10.2 вчера всё работало после аналайза сломалось ... и не понятно , почему update происходит очень очень долго но при тонне активным пользователей критично

а локи на ней какие?

выгнали всех , делаешь апдейт поля

27 сек

День добрый ! есть проблема оперативного характера , не происходит update в одной из крупных таблиц нужна консультация вчера усё работало pg 10.2 вчера всё работало после аналайза сломалось ... и не понятно , почему update происходит очень очень долго но при тонне активным пользователей критично

bloat смотрели (на wiki есть запросы)? А план UPDATE? В логах есть что-нибудь?

А EXPLAIN (ANALYZE, BUFFERS)?

запускали аналайз

запустили фулл

но это ночью и так отработало

с ааналайзом виснет

с ааналайзом виснет

Ну так отвиснет через полминуты, по идее. ;)

И кстати, я Вам 3 вопроса (направления поиска) задал, что по другим? ;)

GIN индекс короче всё портил ...

на связной таблице

он разросся

каким то офигенным образом

на связной таблице

Как связной? Через триггер (просто любопытно)?

он разросся

фаст апдейт выключи

Привет. Подписывайтесь на канал https://www.youtube.com/c/RuPostgres, сегодня вечером кое-что интересное про Постгрес в Яндексе намечается.

Привет. Подписывайтесь на канал https://www.youtube.com/c/RuPostgres, сегодня вечером кое-что интересное про Постгрес в Яндексе намечается.

И что там будет?

И что там будет?

"Что изменилось за прошедшие годы? Как широко используется Постгрес в российском интернет-гиганте теперь? Какие вызовы сейчас стоят перед нашим гостем?"

У, как интересно...

Илья, а что вам интересно?

Технологии. А не то как их используют.

Ладно, не важно.

Hi... После обновления 9.4 -> 10.2 приплыли. Куда копать? 2018-03-01 14:13:34.892 MSK [10093] ERROR: invalid byte sequence for encoding "UTF8": 0x00 2018-03-01 14:13:34.892 MSK [10093] STATEMENT: select pv.id as prop_id, pv.actual_type_id as prop_actual_type_id, pv.persisted_type as prop_persisted_type, pv.long_value as prop_long_value, sv.string_value as prop_string_value from alf_prop_value pv join alf_prop_string_value sv on (sv.id = pv.long_value and pv.persisted_type = $1) where pv.actual_type_id = $2 and sv.string_end_lower = $3 and sv.string_crc = $4

Hi... После обновления 9.4 -> 10.2 приплыли. Куда копать? 2018-03-01 14:13:34.892 MSK [10093] ERROR: invalid byte sequence for encoding "UTF8": 0x00 2018-03-01 14:13:34.892 MSK [10093] STATEMENT: select pv.id as prop_id, pv.actual_type_id as prop_actual_type_id, pv.persisted_type as prop_persisted_type, pv.long_value as prop_long_value, sv.string_value as prop_string_value from alf_prop_value pv join alf_prop_string_value sv on (sv.id = pv.long_value and pv.persisted_type = $1) where pv.actual_type_id = $2 and sv.string_end_lower = $3 and sv.string_crc = $4

в стековерфлоу? https://stackoverflow.com/questions/1347646/postgres-error-on-insert-error-invalid-byte-sequence-for-encoding-utf8-0x0

вообще обновлять так сильно мажорную версию... смело

в стековерфлоу? https://stackoverflow.com/questions/1347646/postgres-error-on-insert-error-invalid-byte-sequence-for-encoding-utf8-0x0

Не поддерживает - это понятно. А как их туда запихнуть удалось?

Может UTF поменялся? Или просто блок данных занулился и никто не заметил?

Hi... После обновления 9.4 -> 10.2 приплыли. Куда копать? 2018-03-01 14:13:34.892 MSK [10093] ERROR: invalid byte sequence for encoding "UTF8": 0x00 2018-03-01 14:13:34.892 MSK [10093] STATEMENT: select pv.id as prop_id, pv.actual_type_id as prop_actual_type_id, pv.persisted_type as prop_persisted_type, pv.long_value as prop_long_value, sv.string_value as prop_string_value from alf_prop_value pv join alf_prop_string_value sv on (sv.id = pv.long_value and pv.persisted_type = $1) where pv.actual_type_id = $2 and sv.string_end_lower = $3 and sv.string_crc = $4

А как обновляли-то? pg_upgrade или dump/restore?

А как обновляли-то? pg_upgrade или dump/restore?

И так и эдак. Ошибки те же.

И так и эдак. Ошибки те же.

И "так и эдак" обновилось?

И "так и эдак" обновилось?

Да, ошибок не было.

Но при получении приложения в журнале наблюдаю ругань.

Да, ошибок не было.

Так это намекает на то, что 0 байт Вы передаёте в параметрах запроса (или где-то есть implicit cast).

Проверьте все типы в этих таблицах, в общем.

добрый день мне надо найти запись по совпадению внутри диапазона lдопустим мне надо найти 5 и есть запись с 1-10

between?

добрый день мне надо найти запись по совпадению внутри диапазона lдопустим мне надо найти 5 и есть запись с 1-10

https://www.postgresql.org/docs/current/static/rangetypes.html https://www.postgresql.org/docs/current/static/gist-builtin-opclasses.html

проблема в том что max и min в разных полях

так where value between max and min чем не катит?

так where value between max and min чем не катит?

а там разве можно сделать min и max разных полей

проблема в том что max и min в разных полях

сделай функциональный индекс

я, видимо, не понял задачу

я попробовал вот но ошибки select * from route WHERE pre >="6512155" and post<="6512155"

ну так where 6512155 between pre and post

ну так where 6512155 between pre and post

ERROR: column "6512155" does not exist

а pre и post каких типов?

и в твоём варианте с <= какая ошибка?

и у тебя точно постгре? ))

Всем привет

Коллеги, добрый день. А подскажите как постгрес поотлаживать? А то странная история. Выполняю скрипт на удалённой машине /bin/bash /tmp/psqlenv.sh visyond RYETRRP6 Warning: Permanently added '138.197.107.221' (ECDSA) to the list of known hosts. + USER=visyond + DB=visyond + PASS=RYETRRP6 + sudo -u postgres psql -c 'CREATE USER visyond PASSWORD '\''RYETRRP6'\'';' + sudo -u postgres psql -c 'ALTER USER visyond WITH ENCRYPTED PASSWORD '\''RYETRRP6'\'';' + sudo -u postgres psql -c 'CREATE SCHEMA visyond;' + sudo -u postgres psql -c 'DROP DATABASE visyond;' ERROR: database "visyond" does not exist CREATE ROLE ALTER ROLE CREATE SCHEMA То есть мы видим в начале создание юзера, и на всякий случай установка пароля отдельной командой. Но вот когда я пытаюсь с этими данными ломиться в постгре, получаю отлуп, что пароль не верен для юзера свежесозданного.

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

pre character varying(11) NOT NULL, post character varying(11) NOT NULL,

pre character varying(11) NOT NULL, post character varying(11) NOT NULL,

test=# create table route (pre varchar(11), post varchar(11)); CREATE TABLE test=# insert into route values ('1','10000000'); INSERT 0 1 test=# select * from route where '43254' between pre and post; pre | post -----+------ (0 rows) test=# select * from route where 43254 between pre::int and post::int; pre | post -----+---------- 1 | 10000000 (1 row)

я попробовал вот но ошибки select * from route WHERE pre >="6512155" and post<="6512155"

Уж сколько раз твердили миру. В ПГ строка д/б в ОДИНАРНЫХ кавычках!

ну у него варчар ещё, он не так сравнивается, как он ожидает

Т.е. запрос выглядит вот так: select * from route WHERE pre >='6512155' and post<='6512155' если не хочется pre и post приводить к инту, что было бы логично.

к инту надо приводить всё равно

ну у него варчар ещё, он не так сравнивается, как он ожидает

Человек пострадать хочет - пусть страдает. :)

Коллеги, добрый день. А подскажите как постгрес поотлаживать? А то странная история. Выполняю скрипт на удалённой машине /bin/bash /tmp/psqlenv.sh visyond RYETRRP6 Warning: Permanently added '138.197.107.221' (ECDSA) to the list of known hosts. + USER=visyond + DB=visyond + PASS=RYETRRP6 + sudo -u postgres psql -c 'CREATE USER visyond PASSWORD '\''RYETRRP6'\'';' + sudo -u postgres psql -c 'ALTER USER visyond WITH ENCRYPTED PASSWORD '\''RYETRRP6'\'';' + sudo -u postgres psql -c 'CREATE SCHEMA visyond;' + sudo -u postgres psql -c 'DROP DATABASE visyond;' ERROR: database "visyond" does not exist CREATE ROLE ALTER ROLE CREATE SCHEMA То есть мы видим в начале создание юзера, и на всякий случай установка пароля отдельной командой. Но вот когда я пытаюсь с этими данными ломиться в постгре, получаю отлуп, что пароль не верен для юзера свежесозданного.

Заметил ещё одну странность. Выводится в консоль не всё что запускает скрипт, потому что целиком он выглядит так: #!/bin/bash set -xe USER=$1 DB=$1 PASS=$2 sudo -u postgres psql -c "CREATE USER ${USER} PASSWORD '${PASS}';" sudo -u postgres psql -c "ALTER USER ${USER} WITH ENCRYPTED PASSWORD '${PASS}';" sudo -u postgres psql -c "CREATE SCHEMA ${DB};" sudo -u postgres psql -c "DROP DATABASE ${DB};" sudo -u postgres psql -c "CREATE DATABASE ${DB};" sudo -u postgres psql -c "GRANT ALL ON SCHEMA ${DB} TO ${USER}" sudo -u postgres psql -c "GRANT ALL ON ALL TABLES IN SCHEMA ${DB} TO ${USER}" Но вывод резульатов работы скрипта обрывается на CREATE SCHEMA, то есть на команде sudo -u postgres psql -c "CREATE SCHEMA ${DB};" как-будто всё кончается, хотя в скрипте ещё остаётся 4-ре команды.

Юзер при этом создаётся postgres=# \du List of roles Role name | Attributes | Member of -----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} visyond | | {} Но видимо пароль не сеттится или как-то криво сетттся, потому что не пускает с ошибкой аутентификации.

а зачем тебе в скрипте альтер пароля

а зачем тебе в скрипте альтер пароля

Ну я написал там выше, на *всякий случай*, видимо потому что первая команда так же не давала нужнго результата.

Заметил ещё одну странность. Выводится в консоль не всё что запускает скрипт, потому что целиком он выглядит так: #!/bin/bash set -xe USER=$1 DB=$1 PASS=$2 sudo -u postgres psql -c "CREATE USER ${USER} PASSWORD '${PASS}';" sudo -u postgres psql -c "ALTER USER ${USER} WITH ENCRYPTED PASSWORD '${PASS}';" sudo -u postgres psql -c "CREATE SCHEMA ${DB};" sudo -u postgres psql -c "DROP DATABASE ${DB};" sudo -u postgres psql -c "CREATE DATABASE ${DB};" sudo -u postgres psql -c "GRANT ALL ON SCHEMA ${DB} TO ${USER}" sudo -u postgres psql -c "GRANT ALL ON ALL TABLES IN SCHEMA ${DB} TO ${USER}" Но вывод резульатов работы скрипта обрывается на CREATE SCHEMA, то есть на команде sudo -u postgres psql -c "CREATE SCHEMA ${DB};" как-будто всё кончается, хотя в скрипте ещё остаётся 4-ре команды.

Сначала надо делать ДРОП ДАТАБАЗЕ, потом КРЕЭЙТ ДАТАБАЗЕ, а потом уже КРЕЭЙТ СХЕМА.

Воот, я так и думал, что могут быть проблемы в последовательности действий. Щас попробую

Воот, я так и думал, что могут быть проблемы в последовательности действий. Щас попробую

Стоп. Еще не всё!

Ну да, это к юзеру вроде не относится

После создания БД, строка подключения к ПГ должна выглядеть следующим образом: psql <DBNAME> -c "<COMMAND>" В противном случае вы все объекты создадите в БД по-умолчанию для пользователя, которым подключаетесь (postgres)