| name | write-tutorial | |
|---|---|---|
| description | Write a structured, pedagogically sound technical tutorial following established conventions — step-by-step walkthroughs with prediction prompts, alert boxes, verification queries, and concept-before-use ordering | |
| argument-hint |
|
You are writing a technical tutorial. Follow this workflow and the rules below. For concrete examples of each pattern, read reference.md in this skill directory.
The first tutorial covered native PostgreSQL partitioning mechanics. This one focuses on the operational payoff — using partitioning for data lifecycle management.
The scenario: An application generates short-lived activation codes with a 12-hour TTL. A nightly job deletes all expired codes with DELETE FROM ... WHERE expires_at < now(), scanning and deleting rows one by one. With range partitioning on expires_at, expired codes naturally land in "cold" partitions that can be dropped instantly — no row scanning, no WAL generation, no vacuum pressure.
We'll use pg_partman to automate partition creation and retention.
Requirements: PostgreSQL 13 or later. pg_partman must be installed as an extension — it's pre-installed on managed services like Crunchy Bridge and available as a system package on most Linux distrib
PostgreSQL's declarative partitioning lets you split a single logical table into smaller physical tables (partitions) based on column values. The database routes inserts automatically — queries against the parent table seamlessly fan out across all partitions.
This tutorial walks through range partitioning by date, using thermostat sensor data as our scenario. We'll deliberately leave a gap in our partition scheme, watch data fall into the default partition, then fix it — giving you a concrete feel for how partitioning behaves in practice.
Requirements: PostgreSQL 11 or later. Every SQL block is self-contained and copy-paste ready.
The recommendations here start with the assumption, there is no way to keep a bike from being stolen, only ways to make it harder to steal. I think about where I’m locking up the bike and how long it will be there. At first, bike security can feel overwhelming. In practice we tend to re-use the same spots for locking up a bike frequently. There is some up front thought and then it turns into habit.
Products in order of importance to me:
| sub vcl_recv { | |
| #FASTLY recv | |
| # Normally, you should consider requests other than GET and HEAD to be uncacheable | |
| # (to this we add the special FASTLYPURGE method) | |
| if (req.method != "HEAD" && req.method != "GET" && req.method != "FASTLYPURGE") { | |
| return(pass); | |
| } | |
| return(lookup); |
| [Unit] | |
| Description=AutoSSH service to remotely access signald's unix socket for weechat's signal.py (/smsg +145789323231) | |
| After=network-online.target | |
| # Use this instead if autossh will interact with the local SSH server | |
| # After=network-online.target sshd.service | |
| [Service] | |
| Environment="AUTOSSH_GATETIME=30" | |
| Environment="AUTOSSH_POLL=30" | |
| Environment="AUTOSSH_FIRST_POLL=30" |
| modules: | |
| http_2xx: | |
| prober: http | |
| http: | |
| preferred_ip_protocol: "ip4" |
Add the following chunk to your existing ISC dhcpd.conf file.
if exists user-class and ( option user-class = "iPXE" ) {
filename "http://boot.smidsrod.lan/boot.ipxe";
}
else {
filename "undionly.kpxe";
}
(or see https://gist.github.com/4008017 for a more elaborate setup
| #!/bin/bash | |
| make_ipxe() { | |
| pushd "$HOME/src/forked/ipxe/src" >/dev/null && | |
| make CONFIG=chain bin/undionly.kpxe bin/ipxe.lkrn bin/ipxe.pxe bin/ipxe.usb && | |
| sudo install -v -m 0644 -g root -o root bin/undionly.kpxe /srv/salt/tftpd/files/undionly.kpxe && | |
| sudo install -v -m 0644 -g root -o root bin/ipxe.lkrn /srv/salt/tftpd/files/ipxe.lkrn && | |
| sudo install -v -m 0644 -g root -o root bin/ipxe.pxe /srv/salt/tftpd/files/ipxe.pxe && | |
| sudo salt-call -l quiet state.single file.recurse name=/srv/tftp source=salt://tftpd/files dir_mode=755 file_mode=644 && | |
| popd >/dev/null |