Re: Server instrumentation for 8.1
От | Bruce Momjian |
---|---|
Тема | Re: Server instrumentation for 8.1 |
Дата | |
Msg-id | 200506050337.j553bEA05758@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Server instrumentation for 8.1 (Rod Taylor <pg@rbt.ca>) |
Список | pgsql-hackers |
Well, that's clear evidence that the only way we are going to be able to SIGTERM a backend is it does a query cancel first, then terminates. I don't think anything else is going to work cleanly. --------------------------------------------------------------------------- Rod Taylor wrote: > > > Exactly. In theory it probably works fine to allow one backend to exit > > > via kill -TERM, but it cannot be claimed that that behavior has been > > > tested to any significant extent --- "fast" shutdown is not stressing it > > > in the same way. > > > > > > I think this is largely a question of someone doing a significant amount > > > of stress testing: gun live server processes with "kill -TERM" in an > > > active system, and keep an eye out for resource leaks, held locks, and > > > so on. It would be more convincing if the processes getting zapped are > > > executing a wide variety of SQL, too --- I'd not feel very confident > > > given only tests of killing, say, pgbench threads. > > > > > > > Cause I know you wont be satisfied with anecdotal evidence, I thought I would > > just say that I have done kill's on specific backends in a high load OLTP > > process, with 1000+ active connections, for years and not had a problem with > > it yet. > > > > Not that I wouldn't like to see some specific, thorough testing on the matter, > > but I'm perfectly comfortable with the previously provided function. > > I've also used it regularly for a few years with 100 active connections > in order to get rid of processes which were doing things they shouldn't > be, and have run into problems. > > It seems about one out of every 20 kills of something holding a heavy > lock (VACUUM, ALTER TABLE, etc.) will result in a lock table corruption > being reported within the next few hours, although the pg_locks view > doesn't show anything interesting, nor do the locks appear to persist as > other processes can use the structures. > > -- > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: