On Sun, Dec 30, 2018 at 07:47:05PM -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > I'm thinking the server should manage this; during startup, create > > $stats_temp_directory/PostgreSQL.$postmaster_pid and store each stats file > > therein. > > +1 > > > Just before creating that directory, scan $stats_temp_directory and > > delete subdirectories that no longer correspond to live PIDs. > > Hm, seems potentially racy, if multiple postmasters are starting > at the same time. The only one you can be *sure* is dead is one > with your own PID.
True; if a PID=123 postmaster launches and completes startup after a slightly-older PID=122 postmaster issues kill(123, 0) and before PID=122 issues unlink()s, PID=122 unlinks files wrongly. I think I would fix that with fcntl(F_SETLKW)/Windows-equivalent on some file in stats_temp_directory. One would acquire the lock before deleting a subdirectory, except for a postmaster deleting the directory it created. (If a postmaster finds a stale directory for its PID, delete that directory and create a new one. Like any deletion, one must hold the lock.) (Alternately, one could just accept that risk.) Another problem comes to mind; if postmasters of different UIDs share a stats_temp_directory, then a PID=1234 postmaster may find itself unable to delete the stale PostgreSQL.1234 subdirectory owned by some other UID. To fix that, the name pattern probably should be $stats_temp_directory/PostgreSQL.$euid.$postmaster_pid.