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

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

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

Use uuid-ы, однако. CREATE EXTENSION pgcrypto, ф-ия get_random_uuid

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

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

PG extension uuid-ossp быть может вам поможет?

коллеги, доброго утра. подскажите, на standby серверах невозможно реализовать запись через dblink? есть master+standby на pg9.6. соответственно, настроен foreign server, user mapping и foreign table. собственно, можно ли считывая данные со слейва, обратиться к foreign таблице, и записать в нее результат?

Всем привет) кто подскажет может книгу по postgresql?

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

А зачем вам это нужно? Тестовые данные генерировать? Или имитация security? ;)

Всем привет) кто подскажет может книгу по postgresql?

t.me/itliba/177 и ещё одна поискать можно там же

t.me/itliba/177 и ещё одна поискать можно там же

Книга очень так себе, лучше не читать.

Книга очень так себе, лучше не читать.

А что лучше?

Мне лично вообще "везёт" читать плохие книги по PostgreSQL. Но вот, например, "PostgreSQL 9.6 High Performance" Ibrar Ahmed, Gregory Smith. Но это именно "лучше", а не так, чтобы очень хорошая. Проблема с ней в том, что, похоже, это это скорее наспех "адаптированная" "PostgreSQL 9.0 High Performance". :(

У Яндекса идет субботник по базам - можно смотреть в прямом эфире - https://vk.com/club17796776?z=video-17796776_456239124

А зачем вам это нужно? Тестовые данные генерировать? Или имитация security? ;)

решение german tank problem и не таскание уиидов

решение german tank problem и не таскание уиидов

А почему бы просто id-ники "наружу" не выставлять (если это в самом деле так важно)?

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

короче нашел триггер адаптировал переписал ух. генерирует рандомную строку, кверит чекая на уникальность

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

Использовать _где_? Т.е. почему "вместо"?

короче нашел триггер адаптировал переписал ух. генерирует рандомную строку, кверит чекая на уникальность

Какое-то ерундовое решение, IMHO. Причём, даже неважно, какой конкретной задачи. :)

Какое-то ерундовое решение, IMHO. Причём, даже неважно, какой конкретной задачи. :)

почему, гениальное решение лул

более того все юзают, странно что нет в виде красивого плагина. тот же imgur вот

Потому, что чекать _не нужно_. ;) Т.е. _даже если_ вам действительно нужны случайные неповторяющиеся числа / строки из какого диапазона, так и генерируйте их на основе SERIAL.

есть такой способ но это менее красиво

есть такой способ но это менее красиво

Почему, в чём вы видите недостатки?

по ним можно восстановить последовательность айдишников

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

по ним можно восстановить последовательность айдишников

Да, можно... теоретически. Т.е. если используется слабый шифр, если кому-то повезёт угадать "пароль" и т.д. Потому что это действительно похоже на паранойю, и такого проседания производительности (особенно, если сгенерированные значения действительно будут использованы как id-ники непосредственно в таблице) она явно не стоит, IMHO.

так это лучше чем ууииды

короче отсюда взял https://blog.andyet.com/2016/02/23/generating-shortids-in-postgres там и собственно аргументация. чувак красавчик

так это лучше чем ууииды

Ну, знаете... по такой логике, UUID-ы —- это тоже "кривой псевдорандом", по которому можно восстановить последовательность айдишников. ;)

ну хуже уиидов вообще ничего нет :)

эм, что не так с ууидами у тебя?

короче отсюда взял https://blog.andyet.com/2016/02/23/generating-shortids-in-postgres там и собственно аргументация. чувак красавчик

Да уж, "красавчик"... Может, я чего не вижу, но это примерно те же UUID-ы, только _кривые_. :(

Да уж, "красавчик"... Может, я чего не вижу, но это примерно те же UUID-ы, только _кривые_. :(

они меньше

Да уж, "красавчик"... Может, я чего не вижу, но это примерно те же UUID-ы, только _кривые_. :(

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

они меньше

И с существенной (и растущей по мере генерации!) вероятностью коллизий, просто "замечательно". :( Вот скажите, чем вас обычный SERIAL + любой симметричный шифр не устраивает? Мне кажестся, чтобы такое взломать, уже нужна помощь криптоаналитика... От кого защищаетесь? ;)

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

Да даже, к примеру: https://wiki.postgresql.org/wiki/Pseudo_encrypt

И с существенной (и растущей по мере генерации!) вероятностью коллизий, просто "замечательно". :( Вот скажите, чем вас обычный SERIAL + любой симметричный шифр не устраивает? Мне кажестся, чтобы такое взломать, уже нужна помощь криптоаналитика... От кого защищаетесь? ;)

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

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

а "содержат таймстамп" - это ты какой функцией их генеришь и почему ею?

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

Да хотя бы ради того, чтобы избавиться от проблем с коллизиями и производительностью (которые у решения "красавчика" должны быть ещё и похуже, чем у обычных UUID)... Причём, опять-таки, всё это ради того, что выглядит как _паранойя_. ;(

а "содержат таймстамп" - это ты какой функцией их генеришь и почему ею?

я не знаю какой нужно. я вообще просто исхожу что проверка на коллизию снижает радикально толщину поля и все

Да хотя бы ради того, чтобы избавиться от проблем с коллизиями и производительностью (которые у решения "красавчика" должны быть ещё и похуже, чем у обычных UUID)... Причём, опять-таки, всё это ради того, что выглядит как _паранойя_. ;(

но это просто лишняя кверя при инсерте

Да хотя бы ради того, чтобы избавиться от проблем с коллизиями и производительностью (которые у решения "красавчика" должны быть ещё и похуже, чем у обычных UUID)... Причём, опять-таки, всё это ради того, что выглядит как _паранойя_. ;(

вдруг у человека никогда не будет и тысячи вставок в секунду?

но это просто лишняя кверя при инсерте

Нет, не просто... кстати, какая ещё "кверя"? Это должно решаться уникальным индексом + обработкой ошибок. Далее, Вы знаете, что хранимые UUID вызывают проблемы не только из-за своего размера, а как раз из-за своей "случайности"?

если там будет тысячи вставок в секунду можно будет нанять половину этого чатика :)

Нет, не просто... кстати, какая ещё "кверя"? Это должно решаться уникальным индексом + обработкой ошибок. Далее, Вы знаете, что хранимые UUID вызывают проблемы не только из-за своего размера, а как раз из-за своей "случайности"?

Ну можно V1 использовать, там степень случайности меньше - возрастающие значения

вообще user-facing id - хорошая проблема

сродни user friendly URL

Нет, не просто... кстати, какая ещё "кверя"? Это должно решаться уникальным индексом + обработкой ошибок. Далее, Вы знаете, что хранимые UUID вызывают проблемы не только из-за своего размера, а как раз из-за своей "случайности"?

А что за проблемы из-за «случайности»?

А что за проблемы из-за «случайности»?

в индексе рандомные страницы обновляются на вставке, вал растёт, кеши вытесняются

А что за проблемы из-за «случайности»?

Доступ в индексе не каждый раз на последнюю страницу, а по случайному пути... а, меня уже опередили. ;)

Спасибо!

Всем привет, подскажите как решить эту проблему. Все,что советуют в гугл не помогло psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

ты или не запустил постгрес, или не на том порту, или не на той машине, или грохнул сокет, или сокет не в том месте

Всем привет, подскажите как решить эту проблему. Все,что советуют в гугл не помогло psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

т.е. с pg_hba.conf всё в норме?

ERROR: S client not available

psql -h /tmp

т.е. с pg_hba.conf всё в норме?

вроде как да

psql -h /tmp

пробрасывает ту же ошибку

ты или не запустил постгрес, или не на том порту, или не на той машине, или грохнул сокет, или сокет не в том месте

тогда вот это

ты или не запустил постгрес, или не на том порту, или не на той машине, или грохнул сокет, или сокет не в том месте

Постгрес запущен, порт 5432. А каким образом посмотреть на состояние сокета?

ls

глазами в файловой системе

Как считаете хорошая ли практика использовать logical decoding для доставки сообщений в Kafka/Rabbit ? Для асинхронной обработки.

надежнее способа достать данные из базы нет

с альтерочками только надо аккуратно

Ок, спасибо

http://thebuild.com/presentations/pgnordic-2018-terrible.pdf дискас

а что, там всё правильно написано

“Why didn’t it collect statistics on the sequential scan it just did?”

http://thebuild.com/presentations/pgnordic-2018-terrible.pdf дискас

да нечего обсуждать. все так и есть что написано. на ноутбуке все ок, дальше как получится

http://thebuild.com/presentations/pgnordic-2018-terrible.pdf дискас

Очень грамотная презенташка.

https://postgrespro.com/list/thread-id/2379543#CAMsr+YHh+5Oq4xziwwoEfhoTZgr07vdGG+hu=1adXx59aTeaoQ@mail.gmail.com

это даже не про постгрес, а про линукс

обновляйте ядра

обновляйте ядра

А толку? Просто уходите с linux (ужас в thread-е в том, что на данный момент linux kernel hacker _и не собираются_ это исправлять). ;)

не используйте writeback? :)

А толку? Просто уходите с linux (ужас в thread-е в том, что на данный момент linux kernel hacker _и не собираются_ это исправлять). ;)

С линукс куда уходить ? На винду чтоли ? Или на живого мертвеца freebsd?

на plan9, конечно

С линукс куда уходить ? На винду чтоли ? Или на живого мертвеца freebsd?

А это уже дело ваше. Линукс такой линукс. ;) Из thread: —— And bitch, loudly and publicly, about how broken this kernel behavior is. If we make enough of a stink maybe it'll get fixed. regards, tom lane —— Т.е. если вам нужен linux, можете присоединяться.

А это уже дело ваше. Линукс такой линукс. ;) Из thread: —— And bitch, loudly and publicly, about how broken this kernel behavior is. If we make enough of a stink maybe it'll get fixed. regards, tom lane —— Т.е. если вам нужен linux, можете присоединяться.

Я думаю в неуловимом джо багов столько что другим не снилось. Просто те 2% не добрались еще до ручки

Эт ж опенсорс — напишите своё :-)

Я думаю в неуловимом джо багов столько что другим не снилось. Просто те 2% не добрались еще до ручки

Одно дело подозрения, а другое : The pre-errseq_t problems are beyond our control. There's nothing we can do about that in userspace (except perhaps abandon OS-buffered IO, a big project). Т.е. в ядрах до 4.13 это даже _выявить_ нельзя, а на более новых PostgreSQL (когда сделают patch) будет просто падать в этой ситуации, если я правильно понял.