PgMail - кто то использовал?

Electric200
Дата: 19.01.2015 21:36:04
Собственно такая вот идейка пришла. Отправка email прям с PlPgSQL при событии тригера. Нагуглил это чудо pgMail
Кто то пользовался? Проект уже три года не обновлялся, также не нашел о совместимости с версиями Pg. Или другой вопрос тогда, как вы организовывали подобную задачу у себя?. Если была такая необходимость.
Собственно задача: при изменении отправлять письмо. Что то вроде RealtimeEvents.
Весь в интерес в том, что инициатором отправки события(Email) может быть приложение с нескольких сторон БД. Соответственно, очень удобно реализовать механиз "отлова" таких сработок централизовано, в самой базе.
Electric200
Дата: 20.01.2015 10:47:32
Или может какой то другой вариант. Т.е какое то приложении мониторит изменение таблицы, и инициализирует отправку email. Требование - мониторинг в режиме реального времени. Т.е никаких кронов и других планировщиков. Очень хочется опираться на инициализацию отправки со стороны БД.
tadmin
Дата: 20.01.2015 11:57:49
Electric200
Нагуглил это чудо

А в чем ваша проблема, в создании самого письма, или в отправке?
Создавать текстовую часть можно чем угодно. Ниже пример на perl.

Отправку можно делать с помощью https://wiki.postgresql.org/wiki/PGQ_Tutorial
Не понимаю, почему вам cron не подходит. Задержка в одну минуту кажется большой?

CREATE OR REPLACE FUNCTION mailer.mailgen(
    mailfrom character varying,
    mailto character varying,
    bcc character varying,
    subject character varying,
    messageid character varying,
    body text,
    attachment text,
    attachmentname character varying)
  RETURNS text AS
$BODY$

use Encode;
use MIME::Lite;
use MIME::Base64;
use utf8;

$mailfrom   =     $_[0];
$mailto     =     $_[1];
$bcc        =     $_[2];
$subject    =     $_[3];
$messageID  =     $_[4];
$body       =     $_[5];
$attachment =     $_[6];
$attachmentName = $_[7];


## Subject encoding -> mime_code -> mark encoding
$subject = encode('utf8', $subject);
$subject = MIME::Base64::encode($subject,"");
$subject = "=?utf-8?B?".$subject."?=";

## Body encode for utf8
$body = encode('utf8', $body);


$msg = MIME::Lite->new(
        From     =>$mailfrom,
        To       =>$mailto,
        Cc       =>$bcc,
        Subject  =>$subject,
        Type     =>'multipart/mixed');

$msg->add("Message-ID", $messageID);

## { add body
    $part1 = MIME::Lite->new(
                            Type     =>'text/html;charset=utf-8',
                            Encoding => 'base64',
                            Data     =>$body
                            );

$msg->attach($part1);
## } add body

## { add atachment
    $part2 = MIME::Lite->new(
                            Type     =>'TEXT',
                            Disposition => 'attachment',
                            Filename => $attachmentName,
                            Data     =>$attachment
                            );

##### { replace atachment tags
    $part2->replace('Content-Transfer-Encoding' => 'base64');
    $part2->replace('Content-Type' => 'application/octet-stream');
##### } replace atachment tags

$msg->attach($part2);
## } add atachment


$message=$msg->as_string;

return $message;
$BODY$
  LANGUAGE plperlu VOLATILE SECURITY DEFINER
  COST 100;
Electric200
Дата: 20.01.2015 14:30:59
tadmin,
Благодарю за пример. Изучаю. Да, любая предусмотренная задержка недопустима.
Electric200
Дата: 20.01.2015 15:35:05
Electric200,
Почитал о PGQ. И на первый взгляд, то что нужно. Завершение инициализирующий транзакции после отправки события в очередь - очень даже не плохо.
Но не совсем понял с consumer. Все таки обращение происходит в виде consumer - > PGQ, а не наоборот. Даже вот есть библиотека на php под это. Но под нее должен быть запущен PHP Daemon, который по сути опрашивает очередь на наличие новый событий. Все дело в том, что хочу избежать PHP демонов. В противном случае мог быть и сам написать что либо подобное. Вот если бы при появлении события, PG вызывал какой либо скрипт PHP и передавал предварительные условия события - это было бы, что доктор приписал. А так я получаю функционала, работа которого зависит от от PHP демона.
tadmin
Дата: 20.01.2015 22:35:48
Electric200
Electric200,любая предусмотренная задержка недопустима.
Откуда такие дикие требования? SMTP сам по себе не гарантирует мгновенной доставки, а от сервера получателя вы и этого просить не можете.
Опрашивайте в бесконечном цикле с небольшими задержками, чтобы не наклонять postgres.

Electric200
Все дело в том, что хочу избежать PHP демонов. В противном случае мог быть и сам написать что либо подобное. Вот если бы при появлении события, PG вызывал какой либо скрипт PHP и передавал предварительные условия события - это было бы, что доктор приписал. А так я получаю функционала, работа которого зависит от от PHP демона.

Любой внешний процесс следует рассматривать потенциально ненадежным, особенно, если он работает с сетью. Чуть что, у вас база встанет колом из-за плохой работы DNS.

То, что вы хотите, похоже на транзакционную отправку почты. Лучший способ выстрелить себе в ногу.
PG вызывал какой либо скрипт PHP - а если этот скрипт завис, у вас будет подвисшая транзакция?
Появляются новые сообщения, вызываются новые PHP скрипты, открывая новые транзакции. Красота!

Для того и придумывают внешние демоны, чтобы не лочить базу данных из-за внешних причин.
Electric200
Дата: 20.01.2015 23:57:42
1. Вполне реальные требования. Роль играют даже секунды.
2. Выше я писал, что о не предусмотренных задержках речи быть не может. Т.е никакие циклы с интервалом, кроны и другой - не подходит. Все это костыли и не является стабильным решением. Если же задержка не предусмотренная (как вы говорите) то ладно. Здесь повлиять уже сложнее на ситуацию.
3. В случае с демоном PHP, то верняк можно прострелить себе ногу. Вы писали когда нибудь демоны на PHP?.
4. Т.е ищу что то на подобии inetd. Демон слушает сокет, при активности создает форк процесса, запускает внешнюю программу и передает ей потом ввода/вывода. В итоге на форках транзакции изолированные, что позволяет не переживать, если упадет один форк, то не отвалится все. Т.е процесс не управляется PHP. Уже лучше как то так.
Собственно мне нужно подобии. При изменении таблицы, запускать внешнюю программу. Можно даже без аргументов. Т.е как видите - вполне реально все.
йоксель
Дата: 21.01.2015 00:21:10
Electric200,

мальчик, ты далпаёп.

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

вот правильно -- нужен журнал отправки (куда можно писать и транзакционно). и джоб типа очереди, как его там, pgq, что ли. с написанным уже воркером (демоном бишь). который эту очередь будет читать, отправлять и пометки в журналке по факту делать. -- чтобы дырки самозатягивались.

а так да -- видел я, как оракул нагибали по самое небалуйсо транзакционной отправкой почты. от боооойшого ума. на сях люди пейсали, не то, что некоторые похабисты.
Electric200
Дата: 21.01.2015 10:11:10
Давайте без ваших йопов.
Т.е хочу что бы данный демон, давал сигнал на внешнюю программу, о том что есть новые события. А дальше уже все остальное. Что бы какой то внутренний механизм следил за изменение состояния событий. И не по типу "а скажи, есть ли у тебя события ", а "дружище, у меня есть новые события". Дальше я уже решу что мне делать.
Пусть это будет внутренний демон PG, все что угодно. Только не демон на PHP.
йоксель
Дата: 21.01.2015 11:01:31
Electric200
Давайте без ваших йопов.
я б с удовольствием, но ведь лезут аж из киеву -- всех не заткнёшь
Electric200
Т.е хочу что бы данный демон, давал сигнал на внешнюю программу, о том что есть новые события.
а внешняя прога -- пьяная в хлам, что тот электрик, лежит, не дышит. Что делать бум ?
Electric200
А дальше уже все остальное.

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