The Linux kernel had a big push to reduce latency, and one of the tricks they did was they replaced the usual interrupt points with a call which noted how long it had been since the last interrupt point. It occurs to me we could do the same for CHECK_FOR_INTERRUPTS() by conditionally having it call a function which calls gettimeofday and compares with the previous timestamp received at the last CFI().
I think the only gotcha would be at CHECK_FOR_INTERRUPTS() calls which occur after a syscall that an actual interrupt would interrupt. They might show a long wait even though an actual interrupt would trigger them right away -- the two that come to mind are reading from the client and blocking on a semaphore. So I think we would need to add a parameter to indicate if that's the case for a given call-site. I think it would be easy to know what value to put there because I think we always do a CFI() immediately after such syscalls but I'm not 100% sure that's the case. Obviously this wouldn't run all the time. I'm not even sure it should run on the build farm because I think doing an extra syscall at these places might mask timing bugs by synchronizing the bus in a lot of places. But even a few build farm animals might uncover places where we don't respond to C-c or hold up the sinval messages etc. It also doesn't replace our current method of responding to user complaints -- many if not all of them are relatively subtle cases where the user is doing something unusual to create a loop that doesn't normally occur. But we won't know that unless we try. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
