Гист ускоряет order by в случае knn, например

ок понял тебя, спасибо ?

ОШИБКА: запрос "SELECT 'Maintance complete for %', current_timestamp" вернул 2 строки

Это как?!

круто, а что за версия?

Grigory Подскажите, в каких случаях возникает ошибка INFO: wait for WAL segment /postgre/back/wal/rshn/00000004000000010000004B to be archived ERROR: switched WAL segment 00000004000000010000004B could not be archived in 300 seconds а то - то работате, то нет. Инкрементальный бэкап делается таким же объемом, что и FULL

круто, а что за версия?

9.6

ОШИБКА: запрос "SELECT 'Maintance complete for %', current_timestamp" вернул 2 строки

А это вообще откуда? Т.е. это запрос сам по себе, или часть чего-то?

Народ, подскажите, а что pg_probackup работает со стандартным постгресом, но с ограничениями в виде использования PTRACK ? (бегло посмотрел, прикольная штука)

Гист ускоряет order by в случае knn, например

что такое knn?

ок, нагуглил

Народ, подскажите, а что pg_probackup работает со стандартным постгресом, но с ограничениями в виде использования PTRACK ? (бегло посмотрел, прикольная штука)

Работает, да. Кажется Grigory даже пакеты собирал.

спасибо

ОШИБКА: запрос "SELECT 'Maintance complete for %', current_timestamp" вернул 2 строки

Похоже еще там может быть ошибка в переводе, возможно там должно быть "вернул 2 столбца"

Grigory Подскажите, в каких случаях возникает ошибка INFO: wait for WAL segment /postgre/back/wal/rshn/00000004000000010000004B to be archived ERROR: switched WAL segment 00000004000000010000004B could not be archived in 300 seconds а то - то работате, то нет. Инкрементальный бэкап делается таким же объемом, что и FULL

pg_probackup ждет появление сегмента вала с LSN от start_backup, проверьте, что archive_command отрабатывает корректно

Народ, подскажите, а что pg_probackup работает со стандартным постгресом, но с ограничениями в виде использования PTRACK ? (бегло посмотрел, прикольная штука)

работает, инструкции по установке пакетов можно найти тут: https://github.com/postgrespro/pg_probackup

pg_probackup ждет появление сегмента вала с LSN от start_backup, проверьте, что archive_command отрабатывает корректно

ERROR: could not open file "/var/lib/pgsql/global/pg_control" for reading: No such file or directory да вроде PGDATA указал

или не туда смотрю

это кто такую ошибку возвращает? archive_command?

можете привести значение параметра archive_command?

да, архив команд

шас

archive_command = 'pg_probackup archive-push -B /postgre/back --instance rshn --wal-file-path %p --wal-file-name %f

Господа, подскажите, не было ли ни у кого проблемы: bz=# vacuum verbose user_profiles; ERROR: could not open file "base/16429/15732634.1" (target block 2680160288): previous segment is only 4627 blocks

archive_command = 'pg_probackup archive-push -B /postgre/back --instance rshn --wal-file-path %p --wal-file-name %f

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

Господа, подскажите, не было ли ни у кого проблемы: bz=# vacuum verbose user_profiles; ERROR: could not open file "base/16429/15732634.1" (target block 2680160288): previous segment is only 4627 blocks

Помог только vacuum full но хотелось бы узнать причину данной ошибки.

Господа, подскажите, не было ли ни у кого проблемы: bz=# vacuum verbose user_profiles; ERROR: could not open file "base/16429/15732634.1" (target block 2680160288): previous segment is only 4627 blocks

файлик побился и частично исчез, и у тебя пропала часть строк из таблицы

кривой rsync, неправильный шатдаун, что-то пошло не так с фс, интересные патчи на постгресе

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

https://pastebin.com/H4eg2LgG

не можем запушить /postgre/data/pg_wal/000000040000000100000045.00000028.backup в /postgre/back/wal/rshn/000000040000000100000045.00000028.backup, потому что такой файл уже есть в архиве они идентичны?

точно два инстанса не льют в один архив?

У меня 1 инстанс

Я игрался с рестором

Наверно надо было создавать новый инстанс восстановленной БД ?

точно два инстанса не льют в один архив?

нет

Наверно надо было создавать новый инстанс восстановленной БД ?

не обязательно

мы при пуше проверяем database id

не можем запушить /postgre/data/pg_wal/000000040000000100000045.00000028.backup в /postgre/back/wal/rshn/000000040000000100000045.00000028.backup, потому что такой файл уже есть в архиве они идентичны?

md5sum разные

скорее всего недописанный файл, содержимое можете привести?

то что /postgre/back/wal/rshn нулевой размер

значит его можно спокойно удалить

шас

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

запустил бэкап PAGE висит 2018-02-14 12:54:47.410 MSK [12463] WARNING: archiving write-ahead log file "000000040000000100000046" failed too many times, will try again later

INFO: wait for LSN 1/4D000028 in archived WAL segment /postgre/back/wal/rshn/00000004000000010000004D

а Вы, когда игрались с restorе, восстанавливали STREAM бэкапы?

кривой rsync, неправильный шатдаун, что-то пошло не так с фс, интересные патчи на постгресе

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

а Вы, когда игрались с restorе, восстанавливали STREAM бэкапы?

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

а размер PAGE по идее меньше должен быть? какой то FULL получается, а не PAGE

А это вообще откуда? Т.е. это запрос сам по себе, или часть чего-то?

CREATE OR REPLACE FUNCTION public.f_maintain() RETURNS text LANGUAGE plpgsql AS $function$ BEGIN raise notice '%', f_purge_tables(); Refresh Materialized view public.m_hosts; Return 'Maintance complete for %', current_timestamp; END; $function$

Похоже еще там может быть ошибка в переводе, возможно там должно быть "вернул 2 столбца"

Он бы вернул первый.

точно два инстанса не льют в один архив?

на самом деле есть один момент, если восстанавливать STREAM бэкап без PITR, то восстановленный инстанс не переключится в новый таймлайн и, имея тот же самый database id с настроенным архивированием он будет архивировать валы в одну директорию с родителем, это плохо

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

Тем не менее, база у Вас битая —- ищите причину / восстанавливайте из backup. :(

Вызываю SELECT public.f_maintain(); в psql - работает минут 20-30. Ошибка не всегда возникает

а размер PAGE по идее меньше должен быть? какой то FULL получается, а не PAGE

да, должен быть меньше

Вызываю SELECT public.f_maintain(); в psql - работает минут 20-30. Ошибка не всегда возникает

Ну так: ERROR: query "SELECT 'Maintance complete for %', current_timestamp" returned 2 columns

А тип результата у Вас text.

Ну так: ERROR: query "SELECT 'Maintance complete for %', current_timestamp" returned 2 columns

Вотоночё... Тогда всё логично.

Вотоночё... Тогда всё логично.

Кстати, это ошибка локализации: msgid "query \"%s\" returned %d column" msgid_plural "query \"%s\" returned %d columns" msgstr[0] "запрос \"%s\" вернул %d строку" msgstr[1] "запрос \"%s\" вернул %d строки" msgstr[2] "запрос \"%s\" вернул %d строк" Т.е. написали бы Вы куда надо. ;)

Кстати, это ошибка локализации: msgid "query \"%s\" returned %d column" msgid_plural "query \"%s\" returned %d columns" msgstr[0] "запрос \"%s\" вернул %d строку" msgstr[1] "запрос \"%s\" вернул %d строки" msgstr[2] "запрос \"%s\" вернул %d строк" Т.е. написали бы Вы куда надо. ;)

С удовольствием, но не знаю - куда.

С удовольствием, но не знаю - куда.

Можно сюда https://www.postgresql.org/list/pgsql-translators/ Но если не хотите возиться с мейлинг листами, то наверное можно сюда https://www.postgresql.org/account/submitbug/

С удовольствием, но не знаю - куда.

Да, наверное лучше в mailing list, например так: https://www.postgresql.org/message-id/5ECB116F-B591-4AD5-AE69-5085F1FDD6A4%40yesql.se

Спасибо!

?

Добрый день господа подскажите пожалуйста есть репликация MASTER-SLAVE что будет если попытаться сделать на SLAVE например UPDATE? сломается репликация? или не выполнится UPDATE?

не выполнится update

Добрый день господа подскажите пожалуйста есть репликация MASTER-SLAVE что будет если попытаться сделать на SLAVE например UPDATE? сломается репликация? или не выполнится UPDATE?

Если физическая репликация то не выполнится

С логической может выполниться

спасибо

есть ли русскоязычный чатик по постгресу в слаке ?

В нем будет 3 человека - делиться бесценным опытом?

есть ли русскоязычный чатик по постгресу в слаке ?

А в чём конкретно вопрос?

А в чём конкретно вопрос?

Просто хотелось узнать , находил только англоязычный Слак намного удобнее имхо

Удобнее то, что знаешь.

коллеги, кто настраивал repmgr, подскажите пжлст, какие права должны быть у replication_user? нигде не могу найти описания

простого replication connect ему явно не хватает

коллеги, кто настраивал repmgr, подскажите пжлст, какие права должны быть у replication_user? нигде не могу найти описания

а что логи настолько удобные что не пишут что происходит и где в чем отказано?

это база: < 2018-02-14 15:07:22.121 MSK > FATAL: password authentication failed for user "repl" < 2018-02-14 15:07:22.121 MSK > DETAIL: Password does not match for user "repl". Connection matched pg_hba.conf line 86: "host replication repl 192.168.1.0/24 md5" это repmgr: [root@pg2 ~]# sudo -u postgres /usr/pgsql-9.6/bin/repmgr -f /etc/repmgr/9.6/repmgr.conf -h 192.168.1.106 -U repmgr -d repmgr standby clone --dry-run -L debug NOTICE: destination directory "/var/lib/pgsql/9.6/data" provided INFO: connecting to source node DETAIL: current installation size is 29 MB DEBUG: upstream_node_id determined as 1 ERROR: connection to database failed: FATAL: password authentication failed for user "repl"

> host replication repl 192.168.1.0/24 md5 у вас пароль не подходит от пользуна repl

ну как бы базе то какой цимес врать

проверил дважды. пересоздал роль с новым паролем и вписал его же в .pgpass

а .pgpass читается? на чем repmgr на libpq работает?

да, на libpq. должен читатся, в конфиг вписан

да, на libpq. должен читатся, в конфиг вписан

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

https://github.com/2ndQuadrant/repmgr/blob/76a93af15c5e665aad5c3d45215116d801ee33d9/HISTORY#L85

какой-то странный параметр

https://github.com/2ndQuadrant/repmgr/blob/76a93af15c5e665aad5c3d45215116d801ee33d9/HISTORY#L80

и упоминание пароля из recovery.conf

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

у меня 4.0, там слегка иначе все, но пароль, как я понимаю, уходит. Вопрос в том, какие права должны быть у replication_user, такое ощущение, что он пытается сделать что-то еще, кроме простой реплики

у меня 4.0, там слегка иначе все, но пароль, как я понимаю, уходит. Вопрос в том, какие права должны быть у replication_user, такое ощущение, что он пытается сделать что-то еще, кроме простой реплики

у вас еще коннекта нет, какие права

Connection matched pg_hba.conf line 86: "host replication repl 192.168.1.0/24 md5" база заматчила по протоколу репликации

но пароль не подошел. еще никаких запросов/директив клиент не успевает спросить

просто в документации пример использует одного юзера (который repmgr), он там прописан как суперюзер и в документации его прописывают как trust. я не могу такое делать на кластере с пользовательскими данными. ага, то есть это именно репликация, это точно? Супер, спасибо. Осталось выяснить, почему пароль не подошел

Ребят) сколько нужно времени, чтобы весь sql проштудировать и уметь хорошо писать запросы?