Даж не думал, что такие длинные имена можно. Хитро Varchar(20) на них не хватает

Надо написать бота, который по +VX,QQ в начале никнейма - будет автоматом бан выписывать.

я думаю лучше просто по длине имени банить)

Вроде как @combot умеет банить спам

Надо написать бота, который по +VX,QQ в начале никнейма - будет автоматом бан выписывать.

ненадёжно. надо проверять по нескольким параметрам. и, вообще, есть ли у телеграма ивент на сообщение "ebobo присоединился к группе"?

я думаю лучше просто по длине имени банить)

или по адресу почты в описании

Как жизнь братан

Лочить этого пидара надо

Лочить этого пидара надо

надо петицию Дурову и телеграм тиме написать, чтобы добавили а апи хук на join message.

они не могут не знать о проблеме

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

надо петицию Дурову и телеграм тиме написать, чтобы добавили а апи хук на join message.

Есть же

можно линк?

а то я искал, но пока не нашёл

Объект Message

new_chat_members

спс, посмотрю вечером, можно ли изменить или заблокировать это сообщение

Там на 10 строчек бот, который будет их удалять и банить

ну тогда надо его написать. не писал ни одного ещё, вот, будет первый, значит ) а то эти упыри уже достали.

Привет! Подскажите как лучше восстанавливать базу к исходной точке. Есть браузерные тесты в тестовой среде с тестовой базой, хочется в самом начале создавать некую точку восстановления и в самом конце к ней сбрасываться. Сейчас читаю про point in time recovery, не уверен, что оно

Привет! Подскажите как лучше восстанавливать базу к исходной точке. Есть браузерные тесты в тестовой среде с тестовой базой, хочется в самом начале создавать некую точку восстановления и в самом конце к ней сбрасываться. Сейчас читаю про point in time recovery, не уверен, что оно

SAVEPOINT ?

не, создай образцовую базу. создай базу под тест create database new template old

и восстанавливайся с темплейта потом

нафиг краш рекавери

не, создай образцовую базу. создай базу под тест create database new template old

Спасибо, похоже что надо

в контектсе параллельных запросов к одной строке, где до транзакции идёт селект, блокировкой FOR UPDATE я смогу изолировать строку даже от SELECT в стороннем запросе пока не закмичу обновление этой строки?

Если "до транзакции", то забудь, это к данной никак не относится.

т.е. селект тоже надо в транзакцию оборачивать?

в контектсе параллельных запросов к одной строке, где до транзакции идёт селект, блокировкой FOR UPDATE я смогу изолировать строку даже от SELECT в стороннем запросе пока не закмичу обновление этой строки?

Т.е. на сколько я тебя понял, твою ситуацию -- нет. UPDATE сделает новую версию данной строки (строк), а другие транзакции смогут читать её предыдущие версии.

т.е. селект тоже надо в транзакцию оборачивать?

От оборачивания SELECT в транзакцию ничего не изменится, он и так транзакция

в контектсе параллельных запросов к одной строке, где до транзакции идёт селект, блокировкой FOR UPDATE я смогу изолировать строку даже от SELECT в стороннем запросе пока не закмичу обновление этой строки?

Что ты понимаешь тут под "изолировать"?

Что ты понимаешь тут под "изолировать"?

если смотреть на всё без параллельных запросов, то взять строчу, помеченную статусом new, поставить ей замок, что её нельзя трогать, пока не обновится статус, внутри транзакции произвести пару апдейтов этой строки и обновить статус

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

причины пока все в догадках

Читай с FOR UPDATE...

походу люди приходят с блокировочников, блокировки это не только падение производительности в результате ожидания но и фича. https://postgrespro.ru/docs/postgresql/9.6/explicit-locking.html

Возможно, ещё select ... for update skip locked поможет

именно это и открыто у меня) только на лайве 9.5

я правильно понимаю, что такую ситуацию на 100% не избежать? Если происходит практически в один момент select и ни один из зарпосов не успевает начать транзакцию, то оба запроса получат одинаковый результат?

т.е. из приложении сначала обращаемся в базу с селект, а потом обращаемся в рамках транзакции

skip locked в 9.5, afaik

От оборачивания SELECT в транзакцию ничего не изменится, он и так транзакция

если селект - транзакция сама по себе, когда она комитится?

если смотреть на всё без параллельных запросов, то взять строчу, помеченную статусом new, поставить ей замок, что её нельзя трогать, пока не обновится статус, внутри транзакции произвести пару апдейтов этой строки и обновить статус

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

если селект - транзакция сама по себе, когда она комитится?

Всё транзакция само по себе. Если не было явного BEGIN, коммитится по завершении statement.

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

не очередь, блокировочник

не очередь, блокировочник

А какая задача-то? Зачем вы вообще явно управляете блокировками?

я правильно понимаю, что такую ситуацию на 100% не избежать? Если происходит практически в один момент select и ни один из зарпосов не успевает начать транзакцию, то оба запроса получат одинаковый результат?

Нет, неправильно. select ... for update..

т.е. из приложении сначала обращаемся в базу с селект, а потом обращаемся в рамках транзакции

Это у тебя хрень какая-то .... start transaction; select * from theQueue where ... for update; ... update ... ... commit; -- or maybe rollback

Это у тебя хрень какая-то .... start transaction; select * from theQueue where ... for update; ... update ... ... commit; -- or maybe rollback

уверен, что хрень

FOR UPDATE ещё и с UNION нельзя

С UNION ALL наверняка можно.

FOR UPDATE ещё и с UNION нельзя

Там вообще много чего нельзя. Агрегаты нельзя. Ну... в общем, правила должны быть как для UPDATABLE VIEW.

Привет всем! Если у меня такая ошибка ALTER TABLE testsch.weather3 ADD COLUMN description2 text; ERROR: must be owner of relation weather3 Как мне получить права на изменение таблицы в схеме, не становясь владельцем этой схемы? Так вообще можно?

Это тебе к админу...

Привет всем! Если у меня такая ошибка ALTER TABLE testsch.weather3 ADD COLUMN description2 text; ERROR: must be owner of relation weather3 Как мне получить права на изменение таблицы в схеме, не становясь владельцем этой схемы? Так вообще можно?

Надо выдать гранты соотв. этому пользователю. Но чаще всего это не имеет смысла, просто надо под овнером схемы всё поменять, и далее работать DML уже под пользователем. Пользователю выдавать права на модификацию схемы (DDL) нет смысла, он это делать в своей обычной работе не должен

С UNION ALL наверняка можно.

к сожалению - нет SQLSTATE[0A000]: Feature not supported: 7 ERROR: FOR UPDATE is not allowed with UNION/INTERSECT/EXCEP

Надо выдать гранты соотв. этому пользователю. Но чаще всего это не имеет смысла, просто надо под овнером схемы всё поменять, и далее работать DML уже под пользователем. Пользователю выдавать права на модификацию схемы (DDL) нет смысла, он это делать в своей обычной работе не должен

Спасибо. Сейчас так и есть. Просто вот есть задача. чтобы был пользователь только с возможнсотью редактирования (без возможости созданих новых схем) какой-либо схемы. Правильно я понимаю, что DDL права пользователю выдать нельзя? (понятно что нет смысла, хотелось бы узнать про саму возможность)

к сожалению - нет SQLSTATE[0A000]: Feature not supported: 7 ERROR: FOR UPDATE is not allowed with UNION/INTERSECT/EXCEP

Ну с union all можно по очереди запросы обрабатывать. Сначала одну часть, если нет ничего , вторую и так далее...

Спасибо. Сейчас так и есть. Просто вот есть задача. чтобы был пользователь только с возможнсотью редактирования (без возможости созданих новых схем) какой-либо схемы. Правильно я понимаю, что DDL права пользователю выдать нельзя? (понятно что нет смысла, хотелось бы узнать про саму возможность)

Это неправильно в корне. Пользователи не должны иметь такую возможность.

к сожалению - нет SQLSTATE[0A000]: Feature not supported: 7 ERROR: FOR UPDATE is not allowed with UNION/INTERSECT/EXCEP

Так зачем вы всё это делаете, если не секрет? Или просто разобраться хотите?

ERROR: S client not available

Спасибо. Сейчас так и есть. Просто вот есть задача. чтобы был пользователь только с возможнсотью редактирования (без возможости созданих новых схем) какой-либо схемы. Правильно я понимаю, что DDL права пользователю выдать нельзя? (понятно что нет смысла, хотелось бы узнать про саму возможность)

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

Спасибо. Сейчас так и есть. Просто вот есть задача. чтобы был пользователь только с возможнсотью редактирования (без возможости созданих новых схем) какой-либо схемы. Правильно я понимаю, что DDL права пользователю выдать нельзя? (понятно что нет смысла, хотелось бы узнать про саму возможность)

А что такое "редактирования схемы"? Создания/удаления объектов в ней, или только изменения самих объектов?

А что такое "редактирования схемы"? Создания/удаления объектов в ней, или только изменения самих объектов?

изменения самих объектов

Тогда я вообще теряюсь...

Привет всем! Если у меня такая ошибка ALTER TABLE testsch.weather3 ADD COLUMN description2 text; ERROR: must be owner of relation weather3 Как мне получить права на изменение таблицы в схеме, не становясь владельцем этой схемы? Так вообще можно?

ALTER TABLE -- это не изменение объектов, это изменение схемы .

ALTER TABLE -- это не изменение объектов, это изменение схемы .

Ссори, значит изменение схемы все таки

ALTER TABLE -- это не изменение объектов, это изменение схемы .

Это как так?

Опять демоны лезут!

Короче понятно, тут без вариантов: "Выполнить ALTER TABLE может только владелец соответствующей таблицы. Чтобы сменить схему или табличное пространство таблицы, необходимо также иметь право CREATE в новой схеме или табличном пространстве." https://postgrespro.ru/docs/postgrespro/10/sql-altertable

Привет всем, незнаю уместен ли тут вопрос.Есть, кто может подсказать, хорошую книгу по postgresql желательно 10тый.И важный момент книгу приобрести хочу именно в бумажном варианте, так как почти на месяц ухожу в поход, где собственно с электричеством проблеммы) Заранее спасибо.

в контектсе параллельных запросов к одной строке, где до транзакции идёт селект, блокировкой FOR UPDATE я смогу изолировать строку даже от SELECT в стороннем запросе пока не закмичу обновление этой строки?

На read commited это можно сделать, если все читающие запросы будут с SELECT ...FOR SHARE. А апдейты с FOR UPDATE.

Привет всем, незнаю уместен ли тут вопрос.Есть, кто может подсказать, хорошую книгу по postgresql желательно 10тый.И важный момент книгу приобрести хочу именно в бумажном варианте, так как почти на месяц ухожу в поход, где собственно с электричеством проблеммы) Заранее спасибо.

м... запросики в тетрадке писать

Читатели не блокируют друг друга, но как только появился писатель все будут ждать

Привет всем, незнаю уместен ли тут вопрос.Есть, кто может подсказать, хорошую книгу по postgresql желательно 10тый.И важный момент книгу приобрести хочу именно в бумажном варианте, так как почти на месяц ухожу в поход, где собственно с электричеством проблеммы) Заранее спасибо.

В поход книгу не бери, 100%

м... запросики в тетрадке писать

на скале, сразу, что бы через несколько тысяч лет археологи гадали, что это за фигня:D

Времени не будет читать, и тащить будешь зря.

да не, время почитать всегда нахожу в походе, на привалах и тд час -два в день будет

На read commited это можно сделать, если все читающие запросы будут с SELECT ...FOR SHARE. А апдейты с FOR UPDATE.

Ты увверен?

да не, время почитать всегда нахожу в походе, на привалах и тд час -два в день будет

На привалах работать надо а не читать

На привалах работать надо а не читать

ну это, если ты прям дикарём)А есль с фирмой, то работать не надо.Максимум палатку поставить)

да не, время почитать всегда нахожу в походе, на привалах и тд час -два в день будет

Я серьёзно тебе говорю, книга -- это кило-полтора минимум. Читать в походе некогда, работать надо. Так что книга должна в походе жить до первого костра или (в водном) до первого порога. Либо в электронном виде

ну это, если ты прям дикарём)А есль с фирмой, то работать не надо.Максимум палатку поставить)

Ну к тому же по PG книг все равно особенно и нету...

ну это, если ты прям дикарём)А есль с фирмой, то работать не надо.Максимум палатку поставить)

Я бы сайт выкачал в электронке, и читал, если уж совсем неймётся...

На read commited это можно сделать, если все читающие запросы будут с SELECT ...FOR SHARE. А апдейты с FOR UPDATE.

Read Committed по умолчанию, по поволу локов не понял какие кому присваивать ,как это for update на update

Read Committed по умолчанию, по поволу локов не понял какие кому присваивать ,как это for update на update

По умолчанию кажется repeatable read

По умолчанию кажется repeatable read

Всё-таки RC. Но можно поменять на любой с помощью default_transaction_isolation.

Я бы сайт выкачал в электронке, и читал, если уж совсем неймётся...

электронки на долго не хватит, но да ладно.Спс за советы)

Возми power bank

ну в целом варик, можно попробовать.)