Re: pg_ctl vs. Windows locking

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> The stats collector processes normally don't shut down until they
>> observe postmaster exit (and I think in CVS tip there's an
>> up-to-one-second delay before they'll even look). Everything else
>> should be gone first though.

> Sounds like a 2 second sleep should do the trick. Will test later.
> Maybe we should do it everywhere, not just Windows, to ensure that we
> don't get nasty interleaving on the log file?

The stats processes won't write anything to the log file under normal
circumstances anyway, so I wouldn't support the above.

A possibly more relevant argument is that if one is using the option to
keep stats totals across postmaster restarts, the old totals aren't
necessarily valid until the old stats processes exit, and so a pg_ctl
restart sequence could fail to transfer the totals.

Maybe we should redesign the shutdown sequence so that the stats
processes get killed quicker. Offhand it seems to me that we could kill
the stats buffer process as soon as the last normal backend is gone, and
let the stats collector process do its shutdown in parallel with the
shutdown checkpoint. I don't believe that a checkpoint operation will
send anything to pgstats, so this wouldn't lose any stats data.
Arguably it would make it more likely that the stats data gets written
--- in the current scheme, the stats collector is the last out the door
and thus in pretty serious risk of being SIGKILL'd by init, if we are in
an init-driven shutdown.

Jan, any thoughts?

regards, tom lane