Рецепты PostgreSQL: планировщик асинхронных задач

[Tantrido]

А патч будет принят в основную ветку?

[TyVik]

Зная сообщество Postgres, не раньше чем через пару лет. В лучшем случае.

Это не упрек комьюнити — просто все патчи долго проверяются, обкатываются и тестируются для надёжности.

[ALepikhov]

Полагаю, шансы этого патча близки к нулю, поскольку сообщество не любит добавлять в СУБД функциональность, которую можно реализовать другими способами или через внешние инструменты.
К тому же не очевидно, что планировщик задач должен быть реализован на уровне СУБД и потенциально снижать надежность оной.

[RekGRpth]

Вообще-то патч — это не планировщик, а исправление ошибки в PL/pgSQL!
А планировщик — это просто расширение.

[ALepikhov]

А, пардон. Я имел в виду, что мало шансов попасть в contrib/

[Melkij]

Как мило, что заявив «пока не удалось пропихнуть в оригинальный репозиторий» вы всё-таки отправили патч в pgsql-hackers. После публикации статьи.

Патч принят не будет. Потому что, процитирую здесь ответ Тома:

The complaint in bug #15738 is 100% bogus

Нельзя так просто в PG_CATCH сделать что-то и не сделать PG_RE_THROW. Чтож, мне за такую попытку тоже уже по голове настучали недавно. См. обсуждения например здесь, здесь

[RekGRpth]

Нельзя так просто в PG_CATCH сделать что-то и не сделать PG_RE_THROW.

Почему нельзя? И где об этом написано?

Вот, например код из оригинального репозитория

void
plperl_spi_commit(void)
{
	MemoryContext oldcontext = CurrentMemoryContext;

	PG_TRY();
	{
		SPI_commit();
		SPI_start_transaction();
	}
	PG_CATCH();
	{
		ErrorData  *edata;

		/* Save error info */
		MemoryContextSwitchTo(oldcontext);
		edata = CopyErrorData();
		FlushErrorState();

		/* Punt the error to Perl */
		croak_cstr(edata->message);
	}
	PG_END_TRY();
}

void
plperl_spi_rollback(void)
{
	MemoryContext oldcontext = CurrentMemoryContext;

	PG_TRY();
	{
		SPI_rollback();
		SPI_start_transaction();
	}
	PG_CATCH();
	{
		ErrorData  *edata;

		/* Save error info */
		MemoryContextSwitchTo(oldcontext);
		edata = CopyErrorData();
		FlushErrorState();

		/* Punt the error to Perl */
		croak_cstr(edata->message);
	}
	PG_END_TRY();
}

[Melkij]

Спросите ответным письмом в hackers. Мол, «я смотрел код в plperl и там сделано так. Это неверно?».

[RekGRpth]

Как мило, что заявив «пока не удалось пропихнуть в оригинальный репозиторий» вы всё-таки отправили патч в pgsql-hackers. После публикации статьи.

Я сообщил об ошибке ещё в начале апреля, но т.к. никто даже ничего и не ответил, то я даже и не пытался предложить им патч, а сделал это после вопроса об этом.

[Melkij]

Именно что «даже не пытался предложить патч» совершенно не вяжется с фразой «пока не удалось пропихнуть». Написали бы что описали баг здесь и локально возможно исправили так — претензии бы не было. А говорить что не удалось пропихнуть патч который даже не отправляли — явно некорректно.

Да, в -bugs могут не ответить. Спустя некоторое время можно вежливо переспросить, мол вопрос остался без внимания, был бы кто-нибудь столь любезен прокомментировать, может я делаю что-то не то и это ожидаемое поведение кода.

[oxff]

А чем ваше расширение лучше pg_cron? Которое, к слову, production ready.

[RekGRpth]

(не лучше, а разница в том), что
1) pg_cron — клиент (для подключения к конкретной базе использует libpq), а у меня работает исключительно на серверной стороне конкретной базы
2) у pg_cron — минимальный интервал — минута, а у меня — миллисекунда
3) для pg_cron требуется установка как расширение, у меня — нет
4) у pg_cron нельзя запускать более одного экземпляра задания одновременно, а у меня — можно

[RekGRpth]

5) pg_cron позволяет запускать только периодические задачи, а у меня можно делать одноразовые, например, выполнить что-то в таком-то году, такого-то числа в такое-то время

[RekGRpth]

(В оригинальном PostgreSQL есть ошибка в PL/pgSQL, из-за которой мой планировщик некорректно работает, когда в задаче, написанной на PL/pgSQL, возникает неперехваченное исключение. Я описал эту ошибку здесь и исправил у себя в форке тут.)

Всё-таки переписал планировщик, чтобы работал и без исправления этой ошибки!

[IgorM23]

Скажите, пожалуйста: а как приостановить работу джоба?

[RekGRpth]

Смотря в каком смысле приостановить. Если задача выполнятся, то её можно отменить/прибить стандартными функциями pg_cancel_backend/pg_terminate_backend, а если надо отменить выполнение запланированной наперёд задачи, то её можно удалить или поставить ей статус STOP.

[aleksey4uk]

Прекрасное расширение. Нам помогло при интеграции из одной бд в другую. Расширение установили на промежуточную базу