Releases: krylosov-aa/pg-status
1.6.1
1.6.0
If a host doesn't respond to a request, it could mean either a temporary issue or that the host is actually down.
To avoid marking a host as dead prematurely, a host is only considered dead after pg_status__max_fails attempts.
To speed up our reaction to possible host unavailability, if a host doesn't respond and the number of attempts
hasn't yet exceeded pg_status__max_fails, we mark it as possibly dead, and this affects which hosts get returned:
- If the current master is marked as possibly dead and there’s already a new master, we immediately switch to the new master.
- When selecting a replica, preference is given to live hosts. However, if no live replicas meet a search criteria, a
potentially dead replica will be returned. This means that for up topg_status__max_failsattempts, the
fairness of load balancing between replicas can be disrupted.
1.5.2
The round-robin algorithm was made more complex, but also more fair, to distribute the load evenly among the replicas. Previously, the replica that came right after the master in the list was returned more often than the other replicas.
1.5.1
- monitor_running flag is implemented as an atomic bool so that the monitoring thread will stop even if, due to sleep=0, stop_pg_monitor can’t acquire the stop_mutex lock
- Wrappers were written around the functions from thread.h to check the returned error codes, and to call abort if something goes wrong
- Added a
/versionAPI for diagnosing the pg-status version
1.5.0
Fixed the data race when updating host status. There are no longer two buffers and a status pointer; instead, there's now a single atomic status field. Since it consists of just four bool values, it occupies only 4 bytes and is therefore lock-free.
The writer atomically updates the status of each host. Readers atomically load the status and can continue working with their local copy as long as needed. Atomic operations are now relaxed, since synchronization with non-atomic data is no longer required.
The only downside of this approach which I don't consider critical for this project is temporary inconsistency while the writer is updating all hosts: some hosts may already have the new data, while others still have the old data.
1.4.3
A small refactoring: proper locking for monitoring thread creation, so an early call to stop_pg_monitor can't happen before the thread actually starts. This wasn't really possible anyway given the code in main, but it makes the code cleaner and more correct.
1.4.2
I replaced waiting for the monitoring thread to start (which used an atomic variable) with a condition variable to speed up the launch
1.4.1
Correctly specified the licenses for external libraries when distributing my application.
1.4.0
- renamed pg_status__port to pg_status__pg_port
- added pg_status__http_port
1.3.2
performance improved