From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Using PostgreSQL for service discovery and health-check |
Date: | 2023-02-09 15:45:52 |
Message-ID: | CAKFQuwbhecCVLcfPi45aVrvpKVmg1RWRUf9A2QuO1WQ+x2Aniw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 9, 2023 at 8:30 AM Dominique Devienne <ddevienne(at)gmail(dot)com>
wrote:
>
> That's basically my plan. Now come the questions:
> 1) will updating a row every second (for example) create issues?
> 2) if yes to #1 above, what would be good mitigation tactics? Use
> different table for service vs heartbeat? Special kind of table? or
> configured in a particular way?
> 3) if a service crashes, it won't remove its row(s), obviously. What kind
> of mechanism exists to "reap" "zombie" services?
> 4) Related to #3 above, I think built-in "cron"-like services are only
> available via extensions, not in PostgreSQL proper. Why? Seems like such an
> essential service.
> 5) Which cron-like extension to use? Especially since we run both on-prem
> but also in managed-PostgreSQL on the cloud?
>
>
You can probably get good mileage from CREATE UNLOGGED TABLE.
I don't have any particular suggestion for PostgreSQL cron extensions but
I'm fully on board with the current division of responsibilities here.
Such a user-space application isn't something that the core developers
should be worried about nor does such a project really want to be tied to
the release cadence that the server is restricted to.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-02-09 15:51:10 | Re: WHERE col = ANY($1) extended to 2 or more columns? |
Previous Message | Kiriakos Georgiou | 2023-02-09 15:45:21 | Concurrency issue with DROP INDEX CONCURRENTLY |