Re: pg_ctl vs. Windows locking

Tom Lane <[email protected]>
Newsgroups gmane.comp.db.postgresql.devel.win32
Message-ID <[email protected]>
Andrew Dunstan <[email protected]> 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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [email protected] so that your
      message can get through to the mailing list cleanly
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.