9404
Чат русскоязычного сообщества PostgreSQL, здесь мы обсуждаем технические вопросы, для поиска работы и предложения вакансий есть группа https://t.me/pgsqljobs For English discussion visit https://t.me/pg_sql
две строки по 300 символов. Разница в одной букве - последней. Хеш у обеих строк одинаковый. Причём, и с 2a, и c 2b
Читать полностью…
Всем спасибо, я по крайней мере разобрался в причине проблемы
Читать полностью…
Добрый день, ребят. Хочу создать уникальный индекс на nullable колонке. Нужно, чтобы допускалось больше одного null в колонке и индекс распространялся только на не null значения. Реализовал данное поведение накинув фильтр на индекс, но теперь читаю, что постгрес из коробки поддерживает такое поведение. Чем будет отличаться уникальный индекс по умолчанию и определенный с фильтром?
Читать полностью…
при потоковой репликации со слотом именно она используется?
или её надо отдельно запускать в обход потоковой репликации?
это утилита, входящая в состав postgres. стоит postgres? стоит и она.
подключается к обычному физическому слоту репликации (да и без слота вроде тоже может, просто как обычная физическая реплика).
pg_receivewal ничего не удаляет. он только копирует (принимает WAL от pg), а удаляет из pg_wal сам pg (по слоту или по max_wal_size).
как и archive_command, которая сама тоже ничего не удаляет, а только копирует, а удалением из pg_wal занимается pg.
(не, так-то в archive_command понаписать всякого можно, но мы же рассматриваем общий случай её использования)
опять же, не вижу проблемы вычистить wal'ы из каталога, куда они перенеслись с помощью pg_receivewal.
по поводу риска накопления повторяться не буду. =)
отдельным скриптом вычищаете wal'ы из pg_wal?
во-первых, это моветон.
а, во-вторых, ничего не помешает вычищать из pg_wal отдельным скриптом wal'ы и в случае с pg_receivewal.
Попробуйте пароли в 300 и 350 байт (латинских букв, например). Если результат (с одной солью) одинаковый — нет, не багованная. Если разный — багованная.
Читать полностью…
Ну смотрите, в случае слота и потоковой, реплика выключается, и слот начинает копить wal.
Читать полностью…
Ну и путаница! 😁
Если я в библиотеке node.bcrypt.js поставлю 2a, у меня будет багованная версия или нет?
На самом деле там смешная история — он как раз поддержывает 2b. Которая соответствует написанной в своё время спецыфикацыи для 2a. Но в реализацыи 2a основателей всралась ошыбка, потому у openbsd версией 2a помечена багованная реализацыя, а версией 2b — правильная. (Не делайте так, это крокодилий поступок!)
При этом у всех остальных afaik неправильной вообще нет, 2a и 2b совпадают.
Интересно, что даже текст менять не пришлось. По идее, если я найду, как в бекенде зафиксировать 2a, и сделаю уже имеющимся хешам паролей string.replace('$2b$', '$2a$'), то всё наверное должно заработать?
Я не читаю скриншоты текстов.
И что там — разные хэшы выдал, при том, что пароли длинные?
https://github.com/kelektiv/node.bcrypt.js/issues/192
Тут пишут, что только первые 72 символа берутся.
Но это уже наверное не очень касается postgresql
при потоковой репликации между двумя инстансами она не используется, но кодовая база с той подсистемой сервера postgres, которая используется при потоковой репликации между двумя инстансами, у них общая.
запускается pg_receivewal отдельно, ведь решение о том, что нужно архивировать WAL с её помощью, принимается отдельно. сам postgres её никогда не запускает, для приёма физической реплики у него всё есть и так.
я вот только не помню, в какой пакет её пихают (т. е. можно ли её без северной части поставить).
Читать полностью…
Кстати, в постгресовом крипте тожэ баг — вопреки спеке bcrypt 2a — пароль отправляется в локальной кодировке, а не в utf8.
Возникает если в базе кодировка не utf8, сответственно.
а pg_receivewal - это стандартный механизм потоковой репликации?
или это что-то что отдельно надо запускать?
они оттуда копируются в хранилище для basebackup.
а pg_receivewal - это репликация получатся потоковая.
не из pg_wal, а из каталога, куда они перенеслись.
со слотом тоже хороший вариант, но от него отказались как раз из-за риска накопления wal
ну не совсем так.
в файловой реплика сломалась по какой-то причине, wal храниться какое-то время и вычищается отдельным скриптом.
Безопаснее получается в плане влияния на мастер.
а в случае отсутствия слота и использования archive_command команда начинает фейлиться по какой-то причине и инстанс начинает копить wal.
=) так что в плане "копки" wal'ов это шило на мыло имхо. или, как сказал бы Илья, шыло на мыло.
с archive_command та же проблема так то.
а у физической реплики, забираемой через pg_receivewal, в теории влияние минимальнее некуда: запросов на ней не выполняется, блокировок отношений не происходит. она собственно даже apply не делает.
Ещё эта реализацыя соответствует 2y и современной 2a из php, поскольку в своё время в php тожэ всралась ошыбка. И они решыли оставить ошыбочную версию, переименовав её из 2a в 2x (чтобы можно было поменять хэшы паролей и продолжать пользоваться), а нормальную сделать и для маркера 2a и для 2y — второе — чтобы просто было отличить точно небагованный хэш на переходный период.
Ну, у многих теперь есть поддержка маркера 2y. На всякий случай.
да поставь уже pgbackrest, сделай spool-path
отправляй в 2-3 потока архивы пачкой по 1 гигу )
Выглядит так что если на вход crypt подается соль с незнакомым префиксом \ без префикса, то используется режим des