похоже на баг, в общем у меня тоже воспроизводится такое поведение

к сожалению, не сработало

А у меня: --exclude-table-data=schema.sequence вроде работает... А Вы как пробовали?

pg_dump -d testdb -U reader -t test_json -f /tmp/test.dump вот такое в лоб не работает

pg_dump -d test -U reader -t test_json --exclude-table-data=test_json_id_seq -f /tmp/test.dump работает нормально

postgres=# create table test_json (id bigserial, jtext json); CREATE TABLE postgres=# INSERT INTO test_json (jtext) VALUES ('{"key":"value","key2":"value2"}'); INSERT 0 1 postgres=# INSERT INTO test_json (jtext) VALUES ('{"key2":"value2", "key":"value " }'); INSERT 0 1 postgres=# create user reader password 'readpass'; CREATE ROLE postgres=# grant select on test_json to reader; GRANT postgres=# \q [nikor@hill ~]$ pg_dump -U reader -d postgres --data-only--table test_json pg_dump: [archiver (db)] query failed: ERROR: permission denied for relation test_json_id_seq pg_dump: [archiver (db)] query was: SELECT last_value, is_called FROM test_json_id_seq [nikor@hill ~]$

таблица из примера Сергея

наличие флага --column-inserts на ошибку не влияет. И с ним и без она есть

версия постгреса 10.4 )

А у меня: --exclude-table-data=schema.sequence вроде работает... А Вы как пробовали?

а, вот как надо

только при восстановлении из дампа поедет последовательность в serial поле (точнее с 1 опять начнется)

Всем привет. Подскажите пожалуйста. По какой причине не отрабатывает команда select * from pg_reload_conf(); после alter system set port to '54433' ; Т.е. postgres=# select * from pg_reload_conf(); pg_reload_conf ---------------- t (1 row) Пишет что все хорошо. Но когда я делаю show port; у меня выводится старое значение. Т,е. сервер не перечитал конфу. НО, если выйти из psql и через консоль linux перезапустить postgres, то все перезачитывается. В чем может быть косяк?

некоторые параметры, например порт, можно менять только перезапуском, об этом написано в документации

некоторые параметры, например порт, можно менять только перезапуском, об этом написано в документации

А какой можно поменять?)

любой от планировщика, work_mem например

любой от планировщика, work_mem например

Понял, спасибо.

Как думаете, можно ли создавая контейнер postgres подсунуть ему db_dump.tar.gz и выполнить pg_restore . Чтобы при запуске контейнера там была нужная база.

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

А непрерывный бэкап можно сделать только репликацией или есть какой то способ еще?

Имеется ввиду возможность восстанавливать состояние базы на определенный момент времени. Типо снапшота.

То есть сделал снапшот, а потом например на определенное состояние pg_dump /restore такое можно?

@antihaos pg_basebackup+WAL-ы

Да. Спасибо.

А непрерывный бэкап можно сделать только репликацией или есть какой то способ еще?

В "ваш" бекап прилетит дроп с мастера и тю-тю;) https://postgrespro.ru/docs/postgrespro/10/continuous-archiving.html

В "ваш" бекап прилетит дроп с мастера и тю-тю;) https://postgrespro.ru/docs/postgrespro/10/continuous-archiving.html

и что? Он отмотает до этого wal

и как еще собирать wal кроме архивной команды или репликации

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

nested sets

@Stitchpunk будет жить. Поприветствуем!

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

можно попробовать https://postgrespro.ru/docs/postgresql/9.6/ltree

Подскажите, постгре умеет сам нарезать партиции по полю с датой? Или это ручной процесс?

Или может есть какой то пакет, типа dbatools, который за этим бы следил

@real_communistic_manifesto будет жить. Поприветствуем!

( благодарю ;) )

Подскажите, постгре умеет сам нарезать партиции по полю с датой? Или это ручной процесс?

Не знаю как в 10, в остальных версиях только по триггеру.

А как себя показывает постгрес, как NoSQL субд?

Либы косые. А так норм.

Воткнул пг+бакардо в прод вместо монги - живёт.

@xMrArt будет жить. Поприветствуем!

А как себя показывает постгрес, как NoSQL субд?

А зачем? Хочется иметь всё в одном?

А зачем? Хочется иметь всё в одном?

почему бы и нет?

Как показывает практика- нельзя усидеть на всех стульях сразу. Придётся чём-то пожертвовать.

А как себя показывает постгрес, как NoSQL субд?

дефайн nosql

Как показывает практика- нельзя усидеть на всех стульях сразу. Придётся чём-то пожертвовать.

а на примере носкл, чем мы жертвуем?

А как себя показывает постгрес, как NoSQL субд?

Кстати, а что по nosql подразумеваешь?

я бы все-таки очертил тот функционал, который вы ищете и подразумеваете под словом nosql, так как от этого зависят ответы

я бы все-таки очертил тот функционал, который вы ищете и подразумеваете под словом nosql, так как от этого зависят ответы

я ничего не ищу, пока) просто интересуюсь

я ничего не ищу, пока) просто интересуюсь

Ну так поинтересуйтесь для начала, что такое управление (ТАУ, да, и прочие безобразия, грустные для любителей чем-то жертвовать, ага). И как этот термин натягивается на СУБД. А потом попробуйте натянуть сие понятие на известные вам носкули. Будет весело, точно говорю.

Я вот читаю информацию по кластеризации pg и тут чат уже продолжительное время и так и не определился, что за решение в качестве балансировщика master-slave кластера чаще используют?

Я вот читаю информацию по кластеризации pg и тут чат уже продолжительное время и так и не определился, что за решение в качестве балансировщика master-slave кластера чаще используют?

В классическом master-slave кластре на репликах можно выполнять только read-only запросы. И то с осторожностью. Даже при синхронной репликации можно не увидеть своих собственных изменений (закоммиченных киентом до этого). В 10-ке появились способы этого избежать: либо ждать от реплики подверждения того, что транзакция применилась, либо убедится, что своя транзакция закоммичена (чтобы соблюсти причинно-следственную связь). Соответсвенно либо отделение мух от котлет (read-only и read-write запросов) должно делаться самим приложением (которое также может гарантироваать причинно-следствнную связь). Либо это долден делать кто-то ещё. Сейчас это с грехом пополам умеет делать только pgpool. Но он не умеет пулить коннекшины. Соответственно приходится использовать связку pgpool+pgbouncer. Ну и есть ещё мультимастер (у нас в PgProEE есть). Одно из его основных преимуществ как раз заключается в том,. что на любом узле можно выполнять любые запросы. Соответвенно тут load balancing может делаться гораздо проще - случйным или round-robin разбрасыванием запросов по узлам. Правдо надо заметить, что масштабировааться мультимастер будет только на транзакциях с преимущественно read-only запросами. Write маштабирование требует шардинга. Он тоже есть у нас - pg_shardman. Тут запрос отправляется на люьой узел,. а потом переадрисуется на нужный шард(ы).

Добрый день. Может быть у кого-нибудь есть идеи куда копнуть. Django 2.1. Использую ltree. На локале миграция заводится без проблем. Заливаю на хостинг - django говорит при миграции: django.db.utils.ProgrammingError: type "ltree" does not exist На хостинге создаю бд и экстеншн аналогично тому как делаю это на локале. sudo -u postgres psql -c "create user $(whoami);" sudo -u postgres psql -c "alter user $(whoami) createdb;" sudo -u postgres psql -c "create database test_db with owner $(whoami);" sudo -u postgres psql -d template1 -c 'create extension ltree;' При выполнении select * from pg_available_extensions; ltree есть в списке.

версия постгреса точно та же? я создаю чуть по-другому, возможно это и не имеет значения sudo -u postgres psql CREATE DATABASE test_database; CREATE USER test_user WITH password 'qwerty'; GRANT ALL privileges ON DATABASE test_database TO test_user; ALTER USER test_user SUPERUSER; \connect test_database; CREATE EXTENSION ltree;

ах да, помню на версии 9.5 было дело на одном серваке не хотели ставиться решилось так — sudo apt-get install postgresql-contrib-9.5 # if error with create extensions

Да, версии были аналогичные. Вопрос решился выполнением на хостинге: sudo -u postgres psql test_db CREATE EXTENSION ltree;

В классическом master-slave кластре на репликах можно выполнять только read-only запросы. И то с осторожностью. Даже при синхронной репликации можно не увидеть своих собственных изменений (закоммиченных киентом до этого). В 10-ке появились способы этого избежать: либо ждать от реплики подверждения того, что транзакция применилась, либо убедится, что своя транзакция закоммичена (чтобы соблюсти причинно-следственную связь). Соответсвенно либо отделение мух от котлет (read-only и read-write запросов) должно делаться самим приложением (которое также может гарантироваать причинно-следствнную связь). Либо это долден делать кто-то ещё. Сейчас это с грехом пополам умеет делать только pgpool. Но он не умеет пулить коннекшины. Соответственно приходится использовать связку pgpool+pgbouncer. Ну и есть ещё мультимастер (у нас в PgProEE есть). Одно из его основных преимуществ как раз заключается в том,. что на любом узле можно выполнять любые запросы. Соответвенно тут load balancing может делаться гораздо проще - случйным или round-robin разбрасыванием запросов по узлам. Правдо надо заметить, что масштабировааться мультимастер будет только на транзакциях с преимущественно read-only запросами. Write маштабирование требует шардинга. Он тоже есть у нас - pg_shardman. Тут запрос отправляется на люьой узел,. а потом переадрисуется на нужный шард(ы).

А что именно в 10-ке появилось по этому поводу?

Я вот читаю информацию по кластеризации pg и тут чат уже продолжительное время и так и не определился, что за решение в качестве балансировщика master-slave кластера чаще используют?

В дополнение к тому, что написал @knizhnik, учтите вот что: Если Вам нужна именно full-ACID master-slave репликация, то: . Придётся "вручную" управлять транзакциями на master (RC + FOR UPDATE). . Для надёжности Вам потребуется синхронная репликация с несколькими standby, следовательно, придётся подумать и о сопутствующем снижении производительности. Далее, разделять connections на read/only и read/write в приложении — это best practice в данном случае (потому что другие решения — это именно что "с грехом пополам"). И ещё такой совет — осторожнее с мультимастерами. Мне кажется, что нередко поставщики таких решений "забывают" описывать конкретные предоставляемые гарантии надёжности и доступности (особенно в общих описаниях), поэтому, если Вам это важно, нужно разбираться/проверять при выборе решения.

Получается опять все сводится к тому, чтобы строить конкретное решение для себя. :(

А что именно в 10-ке появилось по этому поводу?

удваиваю вопрос) сейчас для проверки того, что слейв догнал текущее состояние мастера, приложение использует такой хак: select extract('epoch' from now()) * 100000 // один раз на мастере select extract('epoch' from pg_last_xact_replay_timestamp()) * 100000 // на слейвах, раз в несколько миллисекунд, пока значение не сравняется или не превысит значение с мастера если в 10 появилось решение "из коробки" для синхронизации слейвов при асинхронной репликации, это будет отличным аргументом для апгрейда с 9.6 )

То есть реально такая схема в целом самая надежная: master-slave + в приложении делить write/read

удваиваю вопрос) сейчас для проверки того, что слейв догнал текущее состояние мастера, приложение использует такой хак: select extract('epoch' from now()) * 100000 // один раз на мастере select extract('epoch' from pg_last_xact_replay_timestamp()) * 100000 // на слейвах, раз в несколько миллисекунд, пока значение не сравняется или не превысит значение с мастера если в 10 появилось решение "из коробки" для синхронизации слейвов при асинхронной репликации, это будет отличным аргументом для апгрейда с 9.6 )

Наверное имеется ввиду синхронное подтверждение записи реплики

То есть реально такая схема в целом самая надежная: master-slave + в приложении делить write/read

Смотря что Вы имеете в виду под словом "надёжная". ;) (Лучшее, что сейчас Вам может дать PostgreSQL на данный момент в плане ACID, я описал выше.)

удваиваю вопрос) сейчас для проверки того, что слейв догнал текущее состояние мастера, приложение использует такой хак: select extract('epoch' from now()) * 100000 // один раз на мастере select extract('epoch' from pg_last_xact_replay_timestamp()) * 100000 // на слейвах, раз в несколько миллисекунд, пока значение не сравняется или не превысит значение с мастера если в 10 появилось решение "из коробки" для синхронизации слейвов при асинхронной репликации, это будет отличным аргументом для апгрейда с 9.6 )

Так это у Вас асинхронная репликация, так что использование таких штук всё равно даёт Вам ориентировочную информацию... (Разве что у Вас есть относительно большие периоды без write-нагрузки на master.) > пока значение не сравняется или не превысит значение с мастера А для чего Вы это используете?

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

Так это у Вас асинхронная репликация, так что использование таких штук всё равно даёт Вам ориентировочную информацию... (Разве что у Вас есть относительно большие периоды без write-нагрузки на master.) > пока значение не сравняется или не превысит значение с мастера А для чего Вы это используете?

один из кейсов: интерфейс веб-приложения ставит фоновый таск (условно считаем, что это insert в таблицу tasks), возвращает его ID в ответе. А дальше страница по таймеру опрашивает готовность этого таска по ID. При этом интерфейс начинает работать с мастером, если не удалось выбрать "не сильно отставший" слейв (по захардкоженному порогу разницы во времени, полученному от запросов выше), либо потребовалось открыть транзакцию или совершить запрос, предполагающий запись. Без такой синхронизации иногда выпадали ошибки о том, что таска с таким id не существует, т.к. данные еще не успевали дойти до выбранного слейва (в периоды интенсивной нагрузки). Еще в коде есть коммент на тему, что ранее для синхронизации использовались pg_current_xlog_location/pg_last_xlog_replay_location, но все равно допускали подобные гонки, поэтому были заменены на сравнение по времени.

один из кейсов: интерфейс веб-приложения ставит фоновый таск (условно считаем, что это insert в таблицу tasks), возвращает его ID в ответе. А дальше страница по таймеру опрашивает готовность этого таска по ID. При этом интерфейс начинает работать с мастером, если не удалось выбрать "не сильно отставший" слейв (по захардкоженному порогу разницы во времени, полученному от запросов выше), либо потребовалось открыть транзакцию или совершить запрос, предполагающий запись. Без такой синхронизации иногда выпадали ошибки о том, что таска с таким id не существует, т.к. данные еще не успевали дойти до выбранного слейва (в периоды интенсивной нагрузки). Еще в коде есть коммент на тему, что ранее для синхронизации использовались pg_current_xlog_location/pg_last_xlog_replay_location, но все равно допускали подобные гонки, поэтому были заменены на сравнение по времени.

Понятно. А не легче было бы просто обрабатывать ситуацию отсутствия task? И, всё же, мне тоже интересно, о чём именно писал Константин. ;)

Понятно. А не легче было бы просто обрабатывать ситуацию отсутствия task? И, всё же, мне тоже интересно, о чём именно писал Константин. ;)

Конкретно в этом кейсе так и можно было поступить, но есть еще сценарии, когда объект не добавляется, а апдейтится. Как один из примеров - ставится таск на обновление данных по сущности от внешнего API, и после его завершения нужно эти данные получить. Собственно под эту задачу такой синхрон и делали, а потом распространили на описанную выше ситуацию, т.к. уже был готовый костыль. Но большей части запросов такая синхронизация не нужна, поэтому делать репликацию синхронной непрактично. Еще важный момент - в системе не бывает ситуации, когда на мастере длительное время нет транзакций (бэкэнд непрерывно генерит много мелких апдейтов), поэтому счетчик pg_last_xact_replay_timestamp() никогда не залипает.

Конкретно в этом кейсе так и можно было поступить, но есть еще сценарии, когда объект не добавляется, а апдейтится. Как один из примеров - ставится таск на обновление данных по сущности от внешнего API, и после его завершения нужно эти данные получить. Собственно под эту задачу такой синхрон и делали, а потом распространили на описанную выше ситуацию, т.к. уже был готовый костыль. Но большей части запросов такая синхронизация не нужна, поэтому делать репликацию синхронной непрактично. Еще важный момент - в системе не бывает ситуации, когда на мастере длительное время нет транзакций (бэкэнд непрерывно генерит много мелких апдейтов), поэтому счетчик pg_last_xact_replay_timestamp() никогда не залипает.

Опять-таки, почему просто не ждать, пока статус task не изменится на нужный? Кроме того, тут ещё зависит от того, зачем (с какой целью) эти данные нужно получить. Я к тому, что в зависимости от конкретной архитектуры репликации и приложения, могут быть неприятные крайние случаи.

добрый день. у нас стали подвисать запросы и лететь ошибки вида "failed to find parent tuple" и тому подобное. пробовали сделать reindex, но он тоже упал с "failed to find parent tuple". Единственное, что гуглится это "снимите дамп и перенакатите", но дамп не может забэкапить одну таблицу. может есть еще какие-то способы?

добрый день. у нас стали подвисать запросы и лететь ошибки вида "failed to find parent tuple" и тому подобное. пробовали сделать reindex, но он тоже упал с "failed to find parent tuple". Единственное, что гуглится это "снимите дамп и перенакатите", но дамп не может забэкапить одну таблицу. может есть еще какие-то способы?

Какие уж тут "способы". :( У Вас битая база, поэтому, в конечном итоге, нужно восстановить backup. А Вы причину того, что она побилась, нашли?

инфраструктурщики говорят, что были проблемы со стораджем

бэкапы не делались и алармы на это не заметили

все бэкапы уже с проблемами

пока удалось сделать pg_dump с таблиц, кроме одной.

Значит, у Вас уже битые данные, и что-то Вы почти наверняка потеряете (или какого-нибудь "мусора" найдёте). :( Но общее направление действий верное — добиться снятия дампа, снести/переинициализировать кластер, накатить дамп (если получится, если нет — накатывать частями/вручную), потом печально разбираться, чего не хватает/лишнее/не так.

инфраструктурщики говорят, что были проблемы со стораджем

А как так вышло, что Вы этого не заметили?

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

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

а потом раскрутили уже до того, что в базе что-то не то)

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

А может, у Вас просто кластер PostgreSQL был без контрольных сумм? ;)

кстати да. без.

контрольные суммы все висят в бэклоге и их не включили пока.

видимо, стоит повысить им приоритет)

кстати да. без.

Ну-ну. Не делайте так никогда (впрочем, Вы уже убедились, я думаю). Ладно, а что у Вас сейчас есть и в каком состоянии? База стоит? Файловая копия есть?

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

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

Зря Вы это делаете... или там не одна база?

Впрочем, неважно — в любом случае, кластер надо будет сносить.

А что именно в 10-ке появилось по этому поводу?

Сорри, это появилось не в 10,. а в 9.6: https://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ 1. Можно установить synchronous_commit=remote_apply тогда мастер будет жадть пока транзакция не применится на реплике: https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION 2. causal reads: дождаться пока конкретная тарнзакция не примемнится на реплике