Re: pg_ctl vs. Windows locking
От | Jan Wieck |
---|---|
Тема | Re: pg_ctl vs. Windows locking |
Дата | |
Msg-id | 40CDD103.8010909@Yahoo.com обсуждение исходный текст |
Ответ на | Re: pg_ctl vs. Windows locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers-win32 |
On 6/14/2004 11:55 AM, Tom Lane wrote: > 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. Yes, killing (or rather closing the pipe to it) early is probably the right idea. The claim it wouldn't carry over the stats is wrong. Worst case an instantaneously restarting postmaster firing off a new collector before the old one has written the final stats can cause stats collected during the last 500 milliseconds to be lost. The new collector could open the old stats file before the old collector did the rename. We don't guarantee loss free stats by design anyway, so some stats lost due to a too fast restarting postmaster aren't any worse than stats lost due to a dropped UDP packet. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers-win32 по дате отправления: