Patches specifically for customers that have detected a problem are obviously going to need to go out as soon as possible.
I have seen software at large companies then take the approach that other customers will get those patches as a service pack at regular scheduled intervals. Normally because the patches take some effort to install and test in the customer environment but in your case it could just be used to lessen the possible impact of the effect you are concerned about.
I have also seen people advocate putting patches up in repositories or on websites where customers can download and install the ones they want to. This can create problems with knowing what patches which customers have, so when they call in with a problem you have to determine exactly what code they are running, but with care that can be tracked. You can then force people to upgrade to one of the larger 'packs' when one is released that bundles up lots of patches.
The exception are security patches. A large Washington based software company has been known to get into hot water by waiting for the third Thursday of the month before releasing critical security patches and information about the hack has leaked out and forced their hand early to even greater embarrassment.
Google chrome gets around the issue by auto updating very frequently, they too require you to cycle the program (restart chrome, or in your case log out). They have now made that normal practice for browsers and people don't even think about it any more. But not everyone can be Google.
SaaS applications get around the whole issue by doing the updates in the background.
However, above all, unless you are doing continuous integration or updating with new user requested features very frequently, then I think we are still in a time when people expect you to have done a decent amount of testing before release. If you would be embarrassed to meet your customers and talk about the frequency of bug fixes, you are probably not doing enough testing. Did you release how much of a risk you were taking before you released the code. There is an argument for releasing very early buggy code as long as you know that is what it is, but I think you need to have a good understanding of your known quality, which means understanding and keeping under control your time to know quality.