G
gus bjorklund
Guest
There is a lot more to the story. Signals can trigger a stop condition (e.g. ctrl-c), clean termination (e.g. SIGHUP) similar to a QUIT statement or a fatal error with no undo (e.g. SIGSEGV). Note that an undo does not have to cause termination of the transaction. It can just cause a rollback of some or all of its actions and then initiate a retry. Furthermore, the action triggered by the signal may have to be postponed. An example of that is a SIGHUP that occurs in the middle of an uninterruptible action such as updating a database buffer or inserting a lock into the lock table. In such a case the operation must be completed in order to avoid corrupting shared memory data structures. So the undo and quit has to be postponed until the main thread reaches a point where those actions can be safely taken. On the other hand, when there is an error like a segmentation fault, access violation, or illegal instruction, we can’t just allow the main thread to continue even if in the middle of an uninterruptible action because the error will just occur again, resulting in an infinite loop. So we must terminate the process with a minimum of cleanup. In such cases, there is infinite loop detection that can shortcut the cleanup and just call exit(). Sometimes that will cause a database shutdown (e.g. incomplete microtransaction) and sometimes it wont. Note that when you are connected to multiple databases, undo actions might be required in none, one, several, or all connected databases. Depending on the nature of the thing that triggers the undo, this may or may not be possible. In your case of SIGINT + pause + SIGHUP, you are interrupting the interrupt handling, which adds further complications depending on when it happens. HTH gus PS: yes, tom sometimes the LBI processing can be skipped. But usually not.
Continue reading...
Continue reading...