The Go os/exec package allows for passing a Context when executing a command, therefore allowing for early termination if the context is canceled. Unfortunately, this comes with a caveat: While the spawned process will be killed, its children will simply be reparented and keep on going. We can work around this by, instead of sending SIGKILL to the process, sending SIGKILL to the entire process group. Note that this is OS-specific and will not work on non-POSIX operating systems.
Read MoreA tale of mysterious WiFi latency spikes on Ubuntu
My ThinkPad T440s (wireless chipset Intel Corporation Wireless 7260) running Ubuntu 22.10 has been exhibiting unexplained periodic latency spikes on WiFi. Observed behavior The spikes occur exactly every 5min and cause the latency to spike from below 10ms to over 100ms. The behavior occurs only on WiFi and not on a wired connection. The latency spikes are not correlated with other devices (e.g. my phone or MacBook). Graph of ping latency (ms) over time (mm:ss) showing spikes every 5min
Read MoreArbitrary step alignment in Prometheus
The problem with step alignment in Prometheus Prometheus has a fixed alignment for all queries that cannot be changed by the user. You can specify an arbitrary step, but you have no control over where the boundaries are set. This is not an issue usually, as you do not care where exactly your 15m or 1h step boundaries are. It does become a problem, however, when dealing with larger steps, such as e.
Read MoreA multi-tenant schema using PostgreSQL row level security
To add multi-tenancy to an existing application I settled on the following: Create a tenant table which holds a row for every tenant. Tenants are externally identified by a unique key. Add a tenant_id column to every existing table which references tenant(id). Create a new role (application) without superuser privileges and grant it ownership of all tables. Create a row level security policy on each table to check that the tenant_id column is equal to current_setting('application.
Read MoreNotes on PostgreSQL row level security
Row level security policies do not apply to the table owner (by default) By default RLS policies are not applied to the table owner - one needs to explicitly specify this using to public. create policy some_policy on some_table for all to public using (...); Row level security policies do not apply to superusers Any user that is a superuser, or has the bypassrls bit set will always bypass the RLS system.
Read More