Re: Autovacuum launcher doesn't notice death of postmaster immediately
От | Zdenek Kotala |
---|---|
Тема | Re: Autovacuum launcher doesn't notice death of postmaster immediately |
Дата | |
Msg-id | 466E8175.20003@sun.com обсуждение исходный текст |
Ответ на | Re: Autovacuum launcher doesn't notice death of postmaster immediately (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
Magnus Hagander wrote: > On Tue, Jun 12, 2007 at 12:23:50PM +0200, Zdenek Kotala wrote: >> Alvaro Herrera wrote: >>> Zeugswetter Andreas ADI SD escribió: >>>>>>>>> The launcher is set up to wake up in autovacuum_naptime >>>> seconds >>>>>>>>> at most. >>>>>> Imho the fix is usually to have a sleep loop. >>>>> This is what we have. The sleep time depends on the schedule >>>>> of next vacuum for the closest database in time. If naptime >>>>> is high, the sleep time will be high (depending on number of >>>>> databases needing attention). >>>> No, I meant a "while (sleep 1(or 10) and counter < longtime) check for >>>> exit" instead of "sleep longtime". >>> Ah; yes, what I was proposing (or thought about proposing, not sure if I >>> posted it or not) was putting a upper limit of 10 seconds in the sleep >>> (bgwriter sleeps 10 seconds if configured to not do anything). Though >>> 10 seconds may seem like an eternity for systems like the ones Peter was >>> talking about, where there is a script trying to restart the server as >>> soon as the postmaster dies. >> There is also one "wild" solution. Postmaster and bgwriter will connect >> with socket/pipe and select command will be used instead sleep. If >> connection unexpectedly fails, select finish immediately and we are able >> to handle this issue asap. This socket should be used also in some >> special case when we need wake up it faster. > > Given the amount of problems we've had with pipes on win32, let's try to > avoid adding extra ones unless they're really necessary. If split-sleep > works, that seems a safer bet. Ok It should be problem. But I'm afraid split-sleep is not good solution as well. It should generate a lot of race condition in start/stop scripts and monitoring tools. Much better should be improve pg_ctl to perform clean up ("pg_ctl cleanup) when postmaster fails. I think we must offer deterministic way to packagers integrator how to handle this issue. Zdenek
В списке pgsql-hackers по дате отправления: