Re: stats_temp_directory conflicts

On Sun, Dec 30, 2018 at 07:47:05PM -0500, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)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.