| 1.1, Аноним (-), 08:55, 04/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Публикация e-mail в удобном для спам ботов виде крайне способствует засорению персонального почтового ящика.
| | |
| |
| 2.2, A.Stahl (ok), 09:01, 04/05/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
 >Публикация e-mail в удобном для ... виде
Это называется вежливость.
Разгадывать ребусы вроде:
o(a+)(искусство по-английски)unov(коммерческая собака)postgrespro(тчк)ru
не в кайф. Особенно если действительно надо выйти на связь.
| | |
| |
| 3.3, Аноним (-), 09:24, 04/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
ИМХО, но это точно не вежливость. Вежливость - это когда для резюме кандидатов открывают отдельный e-mail и, при необходимости, краткий help. А забитый спамом персональный e-mail ведущих разработчиков это, простите, "свинью положили".
| | |
| |
| 4.13, YetAnotherOnanym (ok), 12:15, 04/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Работал в провайдере, на сайте был открытым текстом адрес support@..., редиректился на мой персональный email, на мой же адрес редиректились hd@, helpdesk@, help@, abuse@, webmaster@, postmaster@ и ещё какие-то, все уже не помню. В день - два-три-пять собщений, пик - около десятка, в основном на русском. После обучения SA переставали проходить и они.
| | |
| |
| 5.14, pkdr (ok), 12:39, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Вообще-то rfc5321 как раз требует, чтобы postmaster@ не фильтровался.
Да и abuse@, ИМХО лучше не фильтровать.
| | |
|
|
| 3.4, arzeth (ok), 09:25, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Я ребусы (полегче) встречал только на русских сайтах. А так я вижу только типа mail(at)example(dot)com
| | |
| |
| 4.5, A.Stahl (ok), 09:27, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
>mail(at)example(dot)com
Неужели ты думаешь, что для сборщиков адресов этот адрес хоть как-то отличается от написанного прямым текстом? На улице 21 век, гигагерцовые процессоры и прочие достижения...
| | |
| |
| 5.22, Аноним (-), 18:17, 04/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
От профессионала спасёт только ещё более крутой профессионал. От скриптидис - спасёт.
Та же история с ssh. Держать на стандартном 22 порту или перевесить? :)
Как говаривал старик Шекспирыч: ту бир ор нот ту бир?!
| | |
| |
| 6.48, anonimous (?), 18:53, 13/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Та же история с ssh. Держать на стандартном 22 порту или перевесить? :)
как же смИшно выглядят скриптикиддис перевешивающие с 22 на другой порт.
по-вашему перебор портов для бота более занудная процедура, чем перебор пароля?
добавьте уже один раз в /etc/ssh/sshd_config строку:
AuthenticationMethods publickey
и будет вам счастье
| | |
|
|
|
| 3.6, arzeth (ok), 09:30, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Это называется вежливость.
> Разгадывать ребусы вроде:
> o(a+)(искусство по-английски)unov(коммерческая собака)postgrespro(тчк)ru
> не в кайф. Особенно если действительно надо выйти на связь.
Либо вообще можно было бы так сделать: <span class="email">mail ...AAAATTTT... example ...DOOOT... com</span>, а затем с помощью JS сделать нормальный e-mail.
| | |
| |
| 4.9, Бобазали (?), 10:34, 04/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это называется вежливость.
> Разгадывать ребусы вроде:
> o(a+)(искусство по-английски)unov(коммерческая собака)postgrespro(тчк)ru
> не в кайф. Особенно если действительно надо выйти на связь.
>Либо вообще можно было бы так сделать: <span class="email">mail ...AAAATTTT... example ...DOOOT... com</span>, а затем с помощью JS сделать нормальный e-mail.
А можно просто создать отдельный e-mail аналогичный resume@postgrespro.ru и пояснить, что для быстрой связи с Бортуновым О. письмо должно начинаться фразой : "Вниманию Олега Бортунова". Procmail или иной фильтр облегчит жизнь и оператору и Олегу.
И, возможно, стоит перейти к содержанию новости, форма подачи, похоже получила свою долю внимания.
Можно привести сравнительный пример выгод использования параллельно выполняемых рабочих процессов.
| | |
|
|
| 2.8, Аноним (-), 10:01, 04/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Публикация e-mail в удобном для спам ботов виде крайне способствует засорению персонального
> почтового ящика.
А с приходом Яндекса/GMail'а такая проблема как спам еще существует?
| | |
|
| |
| |
| 3.17, Аноним (-), 16:15, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
это все извращения, локи, ловля исключений. нужно просто сделать нормальный штатный механизм
| | |
|
| 2.20, denis111 (ok), 17:05, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 insert into mytable (col1,col2) (select distinct * from (values ('val1','val2')) as tmp (col1,col2) where not exists (select 1 from mytable t where t.col1 = tmp.col1 and t.col2 = tmp.col2))
| | |
| |
| |
| 4.45, PnDx (ok), 15:26, 06/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Строчкой ниже и с теми же полями. Правда, красота? </sarcasm>
Но реально редко напрягает, т.к. прячется за более высокоуровневым синтаксисом.
| | |
|
|
|
| 1.16, Аноним (-), 16:11, 04/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот интересно, когда появится возможность создавать таблицы в памяти, аналог memory таблиц у MySQL?
| | |
| |
| |
| 3.21, Михрютка (ok), 17:21, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 а они разве какое-то отношение к engine=memory имеют? мне всю дорогу казалось, что нет
| | |
| |
| 4.34, Аноним (-), 23:02, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> а они разве какое-то отношение к engine=memory имеют? мне всю дорогу казалось,
> что нет
Прочитай документацию.
| | |
|
|
| 2.24, Аноним (-), 19:04, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Тоже по этой причине на MySQL висит несколько проектов. Задавал этот вопрос у них на форуме, на что получил ответ - используй memcached. Вот только тогда поддерживать тогда надо не одну базу, а две, и перекидывать данные из одной в другую одним запросом, как это делается в случае MySQL, не получится.
| | |
| |
| 3.27, Аноним (-), 19:39, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Например есть данные, которые вообще нет необходимости писать в пзу, какие-нибудь данные онлайн, например список подключенных абонентов. В некоторых ситуациях можно добавлять и обновлять данные в таблице в памяти и из нее сохранять в таблицу на пзу через какой-то промежуток времени. Это не только ускоряет работу с базой, но и значительно увеличивает срок службы ssd. Таблица в памяти определенно нужная функция, иначеб ее не было в mysql
| | |
| |
| 4.29, Аноним (-), 20:44, 04/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Бгг. "Нетранзакционный DDL - нужная функция, иначе б его не было в MySQL".
| | |
| |
| 5.31, Аноним (-), 21:30, 04/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Далеко не всегда нужны ACID таблицы и транзакции. В моей практике часто встречались задачи, в которых потеря данных за час-два и даже день несущественна. Особенно учитывая редкость отключения электричества и использование ибп. А транзакции можно обеспечить и на memory движке, просто это осталось в разделе "недоделанное", как и тысячи других вещей.
| | |
|
| 4.37, Аноним (-), 00:12, 05/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я для такого использую redis, а когда надо с ним заджойнить - redis FDW. Костыль, но отлично работает (только джойнить надо с CTE на foreign table, иначе redis на каждый id дергается).
| | |
| |
| 5.39, Аноним (-), 09:06, 05/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Redis быстрая и очень гибкая СУБД. Postre и MySQL стоило бы поучиться у нее. Чего только стоит управляемое прозрачное кеширование в ram..., реляционных аналогов к сожалению не предвидется
| | |
| |
| 6.44, Аноним (-), 22:14, 05/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Основной недостаток redis-а - персистенция через fork(): при большом потоке записей copy-on-write может раздуть процессы до срабатывания oom killer. overcommit_memory проблему решает, но костыль еще тот.
| | |
|
|
|
|
|
| 1.40, Прохожий (??), 10:29, 05/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Зачем это? Реализовывать процедуры, которые будут в фоне на стороне базы работать?
| | |
| |
| 2.41, Аноним (-), 16:23, 05/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Как вариант многопоточные хранимки, если например внутри хранимки надо сделать несколько тяжелых запросов, то их можно запустить параллельно
| | |
| 2.46, фыва (?), 16:38, 06/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Два момента где многопоточность будет рулить:
1. неблокирующее чтение, в том числе с нескольких физических устройств сразу (для распределенных таблиц), возможно будет и упреждающее чтение
2. распараллеливание тяжелых запросов где грузится процессор (сортировка, GiST)
| | |
|
|
