From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
---|---|
To: | Dirk Mika <Dirk(dot)Mika(at)mikatiming(dot)de> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: How to run a task continuously in the background |
Date: | 2019-07-16 07:06:44 |
Message-ID: | CAKoxK+6exRv9yeLOpZGdOi6uefPDDF1yBJOj_Ph8Sq8b3CmeaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jul 16, 2019 at 7:32 AM Dirk Mika <Dirk(dot)Mika(at)mikatiming(dot)de> wrote:
> It's not really important that the job runs once a second, but that it starts immediately when I want it to.
>
> If I start a job with pg_cron, it will not be executed until the next full minute at the earliest.
>
> The processing of the data via a job is deliberately chosen so as to separate the insertion of the data from their processing.
So, as far as I understand, you want asynchronously processing data
with a process that can be started manually and/or periodically.
I'm probably unable to see what is the goal, but I would go for a
combined solution:
1) a trigger that notifies an external process
<https://www.postgresql.org/docs/current/sql-notify.html>
2) the process runs when notified (by the trigger) or when started
manually or when started by pg_cron (one per minute).
Of course the process is "internal", so something like a stored
procedure (at least as entry point).
The problem with such solution is about race conditions (what if you
manually start something that is already running?), but I guess you
had this problem on the oracle side too.
Hope this helps.
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Luca Ferrari | 2019-07-16 10:53:26 | Re: help understanding pgbench results |
Previous Message | Luca Ferrari | 2019-07-16 06:27:03 | Re: after restore the size of the database is increased |