VY
это было в 2001-м, сейчас системы отличаются кардинально и баланс счёта меняется сразу.
и человеческий фактор никто не отменял…
и человеческий фактор никто не отменял…
Size: a a a
2020 December 25
Ð
даже банально "лайки" часто можно накрутить просто послав пачку из тысячи параллельных запросов. Нет транзакции - нет проверки, пока первый запрос не пройдет до конца, выполняется разрешение на фронте для остальных
D
Ð
даже банально "лайки" часто можно накрутить просто послав пачку из тысячи параллельных запросов. Нет транзакции - нет проверки, пока первый запрос не пройдет до конца, выполняется разрешение на фронте для остальных
Обычно не так просто, потому что лайк привязан к юзеру. А по смыслу один юзер не может поставить более 1 лайка одной сущности
D
Да и у нормальных сервисов спереди CF стоит, который не даст сделать тысячу параллельных запросов. По крайней мере, с одного хоста
Ð
Обычно не так просто, потому что лайк привязан к юзеру. А по смыслу один юзер не может поставить более 1 лайка одной сущности
я это видел и щупал. Пофиг на то что привязан. Проверка, чтобы один юзер ставил один лайк, если она не загнана в транзакцию или атомарный запрос - легко обходится гонкой.
VY
eventually consistent системы, главное чтобы работало, потом как-нить синхронизируется…
OD
Переслано от ORACLE DBA
Any one know code for Postgresql community version certification exam
Please let me know.
Please let me know.
VY
ORACLE DBA
Переслано от ORACLE DBA
Any one know code for Postgresql community version certification exam
Please let me know.
Please let me know.
there is no community certification for PostgreSQL
B
Господа, а поясние мне пожалуйста как новичку, чем отличаются данные индексы?
INDEX ON … (field1, field2)
от
INDEX ON … (field1) INCLUDE (field2)
В обоих случаях при запросах по field1 и field2 будет "index only scan"?
INDEX ON … (field1, field2)
от
INDEX ON … (field1) INCLUDE (field2)
В обоих случаях при запросах по field1 и field2 будет "index only scan"?
D
Господа, а поясние мне пожалуйста как новичку, чем отличаются данные индексы?
INDEX ON … (field1, field2)
от
INDEX ON … (field1) INCLUDE (field2)
В обоих случаях при запросах по field1 и field2 будет "index only scan"?
INDEX ON … (field1, field2)
от
INDEX ON … (field1) INCLUDE (field2)
В обоих случаях при запросах по field1 и field2 будет "index only scan"?
Использование индекса зависит далеко не только от того, какие поля ты туда включил
B
Использование индекса зависит далеко не только от того, какие поля ты туда включил
Да фиг с ним с использованием :)
Поясните чем отличаются данные индексы.
Они же должны отличаться.
Поясните чем отличаются данные индексы.
Они же должны отличаться.
D
Да фиг с ним с использованием :)
Поясните чем отличаются данные индексы.
Они же должны отличаться.
Поясните чем отличаются данные индексы.
Они же должны отличаться.
Во втором случае не нужно читать таблицу, если тебе нужны данные из поля field2, т.к. их можно считать сразу из индекса при его использовании. Но при этом если ты делаешь UNIQUE индекс, это поле при проверке уникальности участвовать не будет. Точнее не скажу, может ещё какие детали есть
D
В первом случае если ты UNIQUE добавишь, то уникальность будет сразу по обоим столбцам проверяться. То есть второй вариант нужен тогда, когда тебе нужен и уникальный индекс по нескольким полям полям, но по некоторым не нужно ограничение уникальности, например, потому что в WHERE они присутствуют, грубо говоря. То есть это, на самом деле, не очень частая ситуация.
2020 December 26
VY
Господа, а поясние мне пожалуйста как новичку, чем отличаются данные индексы?
INDEX ON … (field1, field2)
от
INDEX ON … (field1) INCLUDE (field2)
В обоих случаях при запросах по field1 и field2 будет "index only scan"?
INDEX ON … (field1, field2)
от
INDEX ON … (field1) INCLUDE (field2)
В обоих случаях при запросах по field1 и field2 будет "index only scan"?
в первом случае ключ поиска состоит из 2 колонок, комбинации значений находятся в дереве поиска (помним, что индекс это 2 структуры: дерево + двусвязный список)
во втором случае ключ только из field1. field2 в дереве нету, значения добавлены только в список (leaf pages)
во втором случае ключ только из field1. field2 в дереве нету, значения добавлены только в список (leaf pages)
DK
Господа, сложный момент. Liquibase-ом накатывалась миграция, состоящая из двух команд: первая удаляла колонку, вторая создавала новую. Процесс миграции был случайно убит.
Теперь таблица, которую миграция затрагивала, вообще не шевелится. Не отвечает даже на
Теперь таблица, которую миграция затрагивала, вообще не шевелится. Не отвечает даже на
\d table_name.DK
Я проверял, что может быть локи какие-то остались, но ничего exclusive не нашёл.
DK
Может быть у вас будут какие-нибудь соображения? А то я уже много чего перепробовал, и не знаю, что ещё можно проверить.
DK
А, блин.
DK
Всё, она ожила. Видимо, транзакция долго откатывалась.
VY
не откатывалась, а скорее всего
ALTER TABLE должна была в базе доработать, она берёт AccessExclusiveLock, никакой доступ к таблице невозможен