Re: Using PostgreSQL for service discovery and health-check - Mailing list pgsql-general

From David G. Johnston
Subject Re: Using PostgreSQL for service discovery and health-check
Date
Msg-id CAKFQuwbhecCVLcfPi45aVrvpKVmg1RWRUf9A2QuO1WQ+x2Aniw@mail.gmail.com
Whole thread Raw
In response to Using PostgreSQL for service discovery and health-check  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: Using PostgreSQL for service discovery and health-check  (Dominique Devienne <ddevienne@gmail.com>)
List pgsql-general
On Thu, Feb 9, 2023 at 8:30 AM Dominique Devienne <ddevienne@gmail.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.


 

pgsql-general by date:

Previous
From: Kiriakos Georgiou
Date:
Subject: Concurrency issue with DROP INDEX CONCURRENTLY
Next
From: "David G. Johnston"
Date:
Subject: Re: WHERE col = ANY($1) extended to 2 or more columns?