On Mon, Mar 21, 2022 at 8:29 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Mon, Mar 21, 2022 at 7:07 PM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Sun, Mar 20, 2022 at 1:34 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > I thought that way because IIUC, when we are locking the database > > > tuple we are ensuring that we are calling > > > ReceiveSharedInvalidMessages() right? And IIUC > > > ReceiveSharedInvalidMessages(), is designed such a way that it will > > > consume all the outstanding messages and that's the reason it loops > > > multiple times if it identifies that the queue is full. And if my > > > assumption here is correct then I think it is also correct that now we > > > only need to worry about anyone generating new invalidations and that > > > is not possible in this case. > > > > Well, I don't see how that chain of logic addresses my concern about > > sinval reset. > > > > Mind you, I'm not sure there's an actual problem here, because I tried > > testing the patch with debug_discard_caches=1 and nothing failed. But > > I still don't understand WHY nothing failed. > > Okay, I see what you are saying. Yeah this looks like a problem to me > as well. I will try to reproduce this issue.
I tried to debug the case but I realized that somehow CHECK_FOR_INTERRUPTS() is not calling the AcceptInvalidationMessages() and I could not find the same while looking into the code as well. While debugging I noticed that AcceptInvalidationMessages() is called multiple times but that is only through LockRelationId() but while locking the relation we had already closed the previous smgr because at a time we keep only one smgr open. And that's the reason it is not hitting the issue which we think it could. Is there any condition under which it will call AcceptInvalidationMessages() through CHECK_FOR_INTERRUPTS() ? because I could not see while debugging as well as in code. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
