Overall, the picture you've painted in your question, and I'll preface my answer with this, is of someone who is a relatively inexperienced developer who is new to a company and learning the ropes but having some trouble. So I'll start there and give you some advice:
Regarding the experienced developer telling you to do things that "don't work": I've been here many times, and I've been on both sides of this situation, both as the inexperienced junior telling the senior that what they want can't be done, except the senior is right and it could actually be done, and also as the experienced senior having a junior tell me that what I want them to do can't be done and having to explain that it can, so I'm intimately familiar with what's going on here. What usually causes this is a lack of experience. The senior developer is usually right when they say something can be done, and the part that's missing is that the junior doesn't know how to do it. To which, if it was me, I would explain to the junior what they need to do and how to do it, but not all senior developers are as generous as I am, and some lash out in frustration.
Here's something to try: Rather than saying "it won't work" or "it can't be done", try asking questions. Instead of "I can't do this, because of XYZ", instead frame it as a question: "If I wanted to do this, I would need to solve problem XYZ, but I can't think of a good solution to that. How would you go about tackling this issue?" A good senior developer would see this as a teaching moment and help you out with that issue to spread their knowledge (note: not all senior developers are good senior developers, so YMMV). A bad senior developer may say something like "that's your problem to figure out", at which point you can ask around to your other coworkers to see if anyone else has an idea, or you can escalate to your boss and say that this senior is not helping you; at most companies it's part of the job description of a senior developer to mentor juniors, and so this is a pretty big issue if he's not doing this.
Another thing to think about is that, if you refuse to do this work (even if it's "impossible"), then someone else has to do it; it has to get done. So when you say "it can't be done", you're not actually saying "it can't be done"; you're actually saying "I won't do it, you have to do it for me", because someone has to do it. Which puts your work on his plate. More on this in a moment.
Regarding code reviews: You used a very poignant word in your question which I think shows the root of the problem. Specifically, you said: "there is no mistake in it". This shows a lack of understanding of the code review process that you need to rectify first. The code review process is not about finding and fixing "mistakes". That's called testing. You test your code to find and fix mistakes, and then once the code has no mistakes, then you send it for code review for other purposes. Specifically, those purposes have to do with things like code style, portability, maintainability, and so on.
Maintainability is the most important and also most often violated part of the code review process so I'll drill a bit more on that one. Basically, the idea is that any code you write should not be understandable only by you. Anyone who reads the code should be able to understand it and, if necessary, fix any bugs in it that might arise, or adjust or augment it in any way. The issue is, if you are the only one who understands the code, and you leave the company, then nobody understands the code, and that's a problem. The code review process is there (in part) to make sure that doesn't happen. Without knowing precisely what comments this other developer is making on your code it's hard to say if the issue is maintainability, but:
Here's something to try: Just do whatever he says. The code review process is intended as a gatekeeping process. Code does not get merged without the approval of at least one other team member. This comes with the responsibility for you that the code is of high quality, and the responsibility for that team member that, if the code is not high quality, then he's on the hook for approving code of low quality. The real truth of code review is that new code is very rarely of high quality; comments on code are normal, and multiple revisions of code are normal. Rather than take these comments and change requests as aggression, take the comments as instruction and teaching: the other developer is taking his time to make comments on your code so that you can learn from them and become a better developer yourself. He's also taking an interest in your code to make sure that it won't break; if the code does break (even if the break is in terms of lack of maintainability and not an actual server crash), then it's your head on the line and you'll be the one who gets punished for it, and this other developer is helping you to make sure that doesn't happen. Treat the code review process with respect; it's not a rubber-stamp process and it's not intended to be.
Working overtime: Normally, I hate working overtime; you can crawl through my SE answer history to see all the times I've written about how bad overtime is. However, this is an exception. In this case, it seems that this other developer (and perhaps your team at large, and this one developer is simply the messenger) sees that you are underperforming: you are saying things "don't work" which this other developer has to then build for you because you can't solve the problem presented to you. You are trying to shirk and complain about the code review process and expecting your subpar code to get rubber-stamped. Don't expect that your boss is not aware of this situation; your boss most certainly is aware.
Here's what's very likely going on behind the scenes: Someone, somewhere, wants you fired, and it's probably not this other developer (it might be your boss). They see that you are underperforming and they see that you are not a good fit for this company, and they want you gone. Someone else has decided that they want to give you a second chance. The idea being that, in the current state of affairs, you are not performing well: you are not completing the tasks assigned to you and you are not presenting work that is up to company standard. However, they see potential in you and they think that eventually this will be fixed. In the meantime, however, the work needs to get done and you are expected to contribute your part. The issue is that you are not able to contribute as much as is required during work hours, so you have to work overtime to complete your expectations.
In essence, someone has put a bet on you and someone has put a bet against you, and right now the person who is putting the bet on you is winning: You can keep your job, and that person will protect you, as long as you get your work done and deadlines met, even if that means working overtime. If you choose not to work overtime, and you fail to meet your deadlines, then the person who is against you will win and you will lose your job.
If you want to keep your job, here's something to try: Take my advice above. Don't say you can't do something, or that something is impossible. Instead, say things like "I don't know how to do XYZ", or "how would you do XYZ", or "I see a problem XYZ, what do you think". And then when that problem gets solved, then you do the work yourself and you deliver results. Then, when you've delivered your code, you accept that your code won't be perfect, you don't take code review comments as an attack, and instead use it as a learning experience to become better, and you do what you're asked to do and you merge your clean code smoothly. In the meantime, you work overtime as necessary to meet your deadlines. Eventually, as you become a better developer, these procedures will go more and more smoothly and you'll find it easier to continue in this situation.
