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 [EMAIL PROTECTED]) > -- 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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
