In more traditional software development cycles, defects are found during a testing phase and in production by users. Defects would be logged in a defect tracker. Depending on the severity of the defects, it could block a release or users and might need fixing asap.
In more Agile software development cycles, defects found during an iteration (Sprint) are fixed during the iteration, if they are a result of changes during the iteration. Production defects would be put on a backlog and prioritized by a business representative (Product Owner). I always advise on using a zero-defect policy, as you don't want to iterate on quicksand and sink deeper and deeper into a brittle application.
Nor Agile, nor traditional software development cycles define how you need to handle defects. Technically you could have the same process for both. But in Agile postponing fixing defects might give the team an unfair feeling of how fast they are going. Defects are part of items (User stories) delivered in the past. If your planning is based on the number of items you process you should always prioritize any defects high to keep your velocity real.