Don’t just communicate the problem, document it
My big concern with the other answers so far: Anything you say along these lines to the typical project manager facing an imminent deadline is likely to be ignored or forgotten. Then, you can still end up being on the hook for insufficiently communicating the risk, if something goes wrong.
Let the project manager know about the issue you have found, and let him know you will document it. You need to be able to point to your due diligence.
Where to document and whom to tell depends on your work environment, but definitely include your boss.
Identify Risk and Impact
You mention the problem is not a critical one but don’t really define what that means. Fleshing that out is your next step.
Do a quick risk and impact analysis identifying the problem, how likely it is to cause a problem (risk) and the severity of the consequences if the risk comes to fruition (impact). Use well-defined terms (that your project manager ought to know) like those found in the link above, but also provide a description backing up your analysis.
Your documentation should also include your recommended course of action. Yes, it is OK to raise a concern and still recommend proceeding with the release. It’s correct to identify the risk.
When is your next release?
If, after completing your risk/impact analysis you are still on the fence about what to recommend, take your release schedule into account. Some imperfect code is OK to release if you can expect to include the fix in two weeks.
If there is the chance that fixing your concern will get “deprioritized” (that is, neglected in favor of the next shiny enhancement) then that is one more reason to document the issue as soon as possible after you discover it: if effectively “starts the clock” on the issue.