|
|
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Собственно такая вот идейка пришла. Отправка email прям с PlPgSQL при событии тригера. Нагуглил это чудо pgMail Кто то пользовался? Проект уже три года не обновлялся, также не нашел о совместимости с версиями Pg. Или другой вопрос тогда, как вы организовывали подобную задачу у себя?. Если была такая необходимость. Собственно задача: при изменении отправлять письмо. Что то вроде RealtimeEvents. Весь в интерес в том, что инициатором отправки события(Email) может быть приложение с нескольких сторон БД. Соответственно, очень удобно реализовать механиз "отлова" таких сработок централизовано, в самой базе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2015, 21:36:04 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Или может какой то другой вариант. Т.е какое то приложении мониторит изменение таблицы, и инициализирует отправку email. Требование - мониторинг в режиме реального времени. Т.е никаких кронов и других планировщиков. Очень хочется опираться на инициализацию отправки со стороны БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2015, 10:47:32 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200 Нагуглил это чудо А в чем ваша проблема, в создании самого письма, или в отправке? Создавать текстовую часть можно чем угодно. Ниже пример на perl. Отправку можно делать с помощью https://wiki.postgresql.org/wiki/PGQ_Tutorial Не понимаю, почему вам cron не подходит. Задержка в одну минуту кажется большой? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2015, 11:57:49 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
tadmin, Благодарю за пример. Изучаю. Да, любая предусмотренная задержка недопустима. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2015, 14:30:59 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200, Почитал о PGQ. И на первый взгляд, то что нужно. Завершение инициализирующий транзакции после отправки события в очередь - очень даже не плохо. Но не совсем понял с consumer. Все таки обращение происходит в виде consumer - > PGQ, а не наоборот. Даже вот есть библиотека на php под это. Но под нее должен быть запущен PHP Daemon, который по сути опрашивает очередь на наличие новый событий. Все дело в том, что хочу избежать PHP демонов. В противном случае мог быть и сам написать что либо подобное. Вот если бы при появлении события, PG вызывал какой либо скрипт PHP и передавал предварительные условия события - это было бы, что доктор приписал. А так я получаю функционала, работа которого зависит от от PHP демона. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2015, 15:35:05 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200Electric200,любая предусмотренная задержка недопустима.Откуда такие дикие требования? SMTP сам по себе не гарантирует мгновенной доставки, а от сервера получателя вы и этого просить не можете. Опрашивайте в бесконечном цикле с небольшими задержками, чтобы не наклонять postgres. Electric200 Все дело в том, что хочу избежать PHP демонов. В противном случае мог быть и сам написать что либо подобное. Вот если бы при появлении события, PG вызывал какой либо скрипт PHP и передавал предварительные условия события - это было бы, что доктор приписал. А так я получаю функционала, работа которого зависит от от PHP демона. Любой внешний процесс следует рассматривать потенциально ненадежным, особенно, если он работает с сетью. Чуть что, у вас база встанет колом из-за плохой работы DNS. То, что вы хотите, похоже на транзакционную отправку почты. Лучший способ выстрелить себе в ногу. PG вызывал какой либо скрипт PHP - а если этот скрипт завис, у вас будет подвисшая транзакция? Появляются новые сообщения, вызываются новые PHP скрипты, открывая новые транзакции. Красота! Для того и придумывают внешние демоны, чтобы не лочить базу данных из-за внешних причин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2015, 22:35:48 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
1. Вполне реальные требования. Роль играют даже секунды. 2. Выше я писал, что о не предусмотренных задержках речи быть не может. Т.е никакие циклы с интервалом, кроны и другой - не подходит. Все это костыли и не является стабильным решением. Если же задержка не предусмотренная (как вы говорите) то ладно. Здесь повлиять уже сложнее на ситуацию. 3. В случае с демоном PHP, то верняк можно прострелить себе ногу. Вы писали когда нибудь демоны на PHP?. 4. Т.е ищу что то на подобии inetd . Демон слушает сокет, при активности создает форк процесса, запускает внешнюю программу и передает ей потом ввода/вывода. В итоге на форках транзакции изолированные, что позволяет не переживать, если упадет один форк, то не отвалится все. Т.е процесс не управляется PHP. Уже лучше как то так. Собственно мне нужно подобии. При изменении таблицы, запускать внешнюю программу. Можно даже без аргументов. Т.е как видите - вполне реально все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2015, 23:57:42 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200, мальчик, ты далпаёп. если тебе надо безответсвенно стартовать процесс - нет никакого смысла ввязывать его в транзакцию -- если он опнется -- кто проследит. что почта куда-то уйдёт? вот правильно -- нужен журнал отправки (куда можно писать и транзакционно). и джоб типа очереди, как его там, pgq, что ли. с написанным уже воркером (демоном бишь). который эту очередь будет читать, отправлять и пометки в журналке по факту делать. -- чтобы дырки самозатягивались. а так да -- видел я, как оракул нагибали по самое небалуйсо транзакционной отправкой почты. от боооойшого ума. на сях люди пейсали, не то, что некоторые похабисты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 00:21:10 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Давайте без ваших йопов. Т.е хочу что бы данный демон, давал сигнал на внешнюю программу, о том что есть новые события. А дальше уже все остальное. Что бы какой то внутренний механизм следил за изменение состояния событий. И не по типу "а скажи, есть ли у тебя события ", а "дружище, у меня есть новые события". Дальше я уже решу что мне делать. Пусть это будет внутренний демон PG, все что угодно. Только не демон на PHP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 10:11:10 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200Давайте без ваших йопов. я б с удовольствием, но ведь лезут аж из киеву -- всех не заткнёшьElectric200Т.е хочу что бы данный демон, давал сигнал на внешнюю программу, о том что есть новые события. а внешняя прога -- пьяная в хлам, что тот электрик, лежит, не дышит. Что делать бум ?Electric200 А дальше уже все остальное. тут такое дело -- синхронному механизму важно положить данное для рассылки в журнал. синхронному механизму допустимо пнуть пьяного электрика, но не отвлекаясь на ожидания (т.е. походя, не гарантированно его поднять-- откуда следует, что мониторинга электриков никто не отменит, будь они на похабе, или чём-то другом) а вот отсылка -- асинхронной очередью в любом случае -- т.к. надо обрабатывать разные непредвиденные ситуации. в т.ч. долгие таймауты, повторные попытки отсыла после простоя, и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 11:01:31 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200, в общем-то наиболее правильное решение вам уже подсказали: письма отправлять синхронно в очередь (pgq), и асинхронно доставать демоном. демон хоть на баше можно написать, там сильно сложного не должно быть ничего. почтовый сервер по идее должнен быть настроен так, что при получении письма он в свою очередь его складывает и потом уже асинхронно отправляет. теоретически можно обойтись и без pgq в таком случае, но это дополнительная точка отказа и потенциальный источник проблем. так что лучше так не делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 12:27:04 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Alexiusпочтовый сервер по идее должне быть настроен так, что при получении письма он в свою очередь его складывает Если уж совсем сходить с ума по идее "доставлять без задержек", то можно с помощью plperl писать скомпонованное письмо на локальный диск (относительно безопасно для транзакций). Насколько помню, postfix способен тут же подхватить файл, если он помещен в нужную папку (spool). Если нет, можно сообщить почтовику через inotify. Это очень быстро. Повторюсь, почтовый сервер никогда не начинает отправку мгновенно. Поэтому сама идея отказа от задержек лишена смысла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 12:42:29 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
PL/Perlu и далее любой модуль с cpan'а, который умеет посылать почту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 13:24:54 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Спасибо уважаемые. Убедили. Буду реализовывать очередь + демон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 14:53:51 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200, Если pgq кажется избыточным и будете делать свой persistent демон, то можно получать уведомлять через async notify. Это мгновенно и бесплатно для БД. Резидентный процесс слушает канал, получает notify, забирает сообщение, отправляет его и помечает отправленным в БД. В случае аварии notify будут потеряны, поэтому при рестарте демона нужно проверить наличие не отправленных сообщений. Напишите - поделитесь. Много кому пригодится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2015, 15:11:19 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
tadmin, Спасибо за наводку на Notify. Но мне кажется, что такое решение при реализации демона на PHP слегка избыточное. Поскольку в демоне, необходимо циклично опрашивать PG через "LISTEN NOTIFY". Также здесь однопоточность и плохая "демонализация" через PHP. Хотя с другой стороны - решение имеет право на реализацию. Но вот наткнулся на интересный пример через Python. Т.е при выполнении тригера PG на Update, с помощью PLPython открываем удаленных хост и бросаем туда то, что нам нужно. На той стороне, я уже могу к примеру через Inetd слушать нужных порт и при получении коннекта, вызывать свой PHP Handler, имея в нем STDIN с сокета. В итоге: 1. Более стабильная и контролированная работа демона Inetd, по сравнению с PHP. 2. Возможность многопоточности за счет того самого Inetd, который создает столько форков, сколько входящих подключений на прослушиваемый сокет. 3. Универсальность. По сути мне не важно откуда я получаю коннекты. Это может быть не только PG. 4. Контролируемость и целостность. На стороне PG, я могу отмечать постановку на отправку , на стороне демона саму - саму отправку. Т.е кручу верчу как хочу. 5. Независимость и изолированность. По сути, если с PG мне не удалось по каким либо причинам открыть удаленный хост, я без проблем могу это обработать как мне нужно, без вредя для транзакции. С со стороны демона - если не удалось отправить, также можно отработать этот момент. Ну вот как то так. Если все это стабильно заработает, то я получу что хотел))) Что думаете господа?) Мальчик снова "долпаеп" ?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2015, 11:54:30 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200Наткнулся на интересный пример через Python. Т.е при выполнении тригера PG на Update с помощью PLPython открываем удаленный хост и бросаем туда то, что нам нужно. Вы вернулись к началу: пока триггер не отработает, транзакция не завершится. NOTIFY же асинхронный: послали — тут же ушел, вам остается только поймать его на другом конце. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2015, 14:49:33 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
А NOTIFY не с того же триггера на UPDATE посылать нужно? Или оно еще как то иначе возможно? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2015, 15:03:57 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200, Также при проблемах с сетью вы либо откатываете успешную по всем другим параметрам транзакцию, либо бесследно теряете свое сообщение. При наличии же локальной очереди вы его получите, как только сеть восстановится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2015, 15:05:48 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
Electric200, из того же, но NOTIFY нетранзакционный: оп просто уходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2015, 15:07:00 |
|
||
|
PgMail - кто то использовал?
|
|||
|---|---|---|---|
|
#18+
А.все.. понял что вы имели виду.. Но вот "ловить" не удобно. Идея с постоянным циклом на получение NOTIFY на другом конце, мне совсем не по душе. Уже лучше я буду через триггер кидать события на другой хост, чем другим хостом снифить базу на наличие новых событий.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2015, 15:11:48 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38858199&tid=1998223]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
180ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 495ms |

| 0 / 0 |
