That feeling is a common one to testers; I don't think you can get away from it.
That said, and the terminology is going to differ depend on how you arrange the development process, I'm assuming you have the following things:
1) Some sort of test plan, ie, a list of scenarios you'll attempt, or function test cases you'll run, or whatever. Ideally, these will have ties to new functions in the code, or are marked as being done for regression purposes. The test plan should have been reviewed by the stakeholders, including development, support, and possibly the client/end user.
2) A problem list, with problems marked as open, closed/fixed, closed/unreproducible, with some sort of customer associated severity associated with each problem.
Given the above, at any given point during the test cycle, you should be able to have some idea of what percentage of your testing has been attempted (test executed but unsuccessful), completed (executed successfully), and bypassed for some reason (can't be executed for some reason).
At the beginning of a development cycle, you should have a discussion with stakeholders over what done means. Typically, this is something along the lines of 100% attempted, 95% complete, with no open severity 1 or 2 problems. Or maybe it's you've run a stress test for 24 hours without any failures. Or you haven't found any severity 1 or 2 problems in a week. Whatever makes sense for the testing you're doing.And once you've met those requirements, you're done.
You can adjust these criteria over time, but this is the best way, at least in my opinion, of declaring you're ready for production. First, you have buy-in from the other stakeholders that this is the right set of things to do to determine you're ready to release, and second, you have a defined set of metrics to use to make that determination.
If for some reason those metrics need to be tweaked, or additional types of testing needs to be done, or whatever, that's fine, and good, but by having a set of metrics you have predefined, you remove the human factor, which is good, possibly necessary, because as a tester, you're always going to think there's something more you could do, one more problem you could find.