RekGRpth Jun 19 2019 at 14:05

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

3 min

9.6K

PostgreSQL*

Tutorial

+13

Comments 14

Tantrido Jun 19 2019 at 16:50

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

TyVik Jun 19 2019 at 23:04

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

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

ALepikhov Jun 20 2019 at 05:47

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

RekGRpth Jun 20 2019 at 05:48

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

ALepikhov Jun 20 2019 at 05:52

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

Melkij Jun 20 2019 at 21:34

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

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

The complaint in bug #15738 is 100% bogus

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

RekGRpth Jun 21 2019 at 05:54

Нельзя так просто в 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 Jun 21 2019 at 07:56

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

RekGRpth Jun 21 2019 at 06:06

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

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

Melkij Jun 21 2019 at 08:06

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

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

oxff Jul 27 2019 at 21:45

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

RekGRpth Jul 28 2019 at 10:22

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

RekGRpth Jul 29 2019 at 05:55

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

RekGRpth Feb 12 2020 at 14:15

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

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

Show the best of all time