pg0 0.15.1: stop rewrites instance.json without pid; subsequent start fails with missing field pid

[jimmywu0816]

Summary

On a clean stop, pg0 rewrites instance.json without the pid field. But start hard-requires pid when deserializing instance state, so any start after a clean stop fails with JSON error: missing field pid until instance.json is manually deleted (pg0 then regenerates it against the existing data dir).

Environment

• pg0 0.15.1 (pg0-embedded Python package), Linux, PostgreSQL 18.1.0 and 18.6.0
• Observed 2026-09-04/05 on Ubuntu; instance under ~/.pg0/instances/<name>/

Repro

1. pg0 start --name demo --version 18.x ... → running
2. pg0 stop --name demo → clean stop, no error
3. cat ~/.pg0/instances/demo/instance.json → JSON has port, data_dir, etc. but no pid key
4. pg0 start --name demo ... → error: missing field pid (deserialization), nonzero exit

Amplifying factors

• Under systemd Restart=on-failure this becomes a tight restart loop: every start fails → the unit restarts every few seconds (we observed 83 consecutive failed restarts during an unrelated crash recovery; PostgreSQL had no listener the whole time).
• Related pid-field edge cases hit the same crash family: pid: null → JSON deserialization crash; pid: 0 → misdetected as running via kill(0) semantics. Deleting instance.json and letting pg0 regenerate it is the only clean recovery.

Expected

Either stop leaves instance.json in a state start accepts (e.g. omit-able pid with #[serde(default)]), or start tolerates a stopped-state instance.json when the data dir exists.

Workaround we shipped (for reference)

A systemd ExecStartPre guard: if instance.json exists but lacks "pid", delete it before start (validated safe against an existing data dir).