Обсуждение: freeze map open item
The open items list says this: heap_update sets xmax and infomask without logging the changes or clearing PD_ALL_VISIBLE or visibility map bits * volunteer owner wanted * This has been buggy essentially forever but the freeze map changes give it new urgency. * Andres working on committing patches I believe this issue was fully resolved by bfa2ab56bb8c512dc8613ee3ff0936568a1c8418. Is that correct? Regardless, I'd like to extend sincere and heartfelt thanks to Andres for handling this issue, because I was sure running out of steam (and time). Two other issues were discussed on that thread for which no open issues were created. First, heap_lock_tuple failed to clear the all-frozen status. I believe that eca0f1db14ac92d91d54eca8eeff2d15ccd797fa substantially addressed that issue and therefore it should be added to the list as a resolved issue. But, second, as noted in further discussion on that thread and in the commit message, there is an outstanding theoretical problem which is non-critical but worthy of being fixed. I recommend we open a new open issue for that, or at least fix it. Comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jul 21, 2016 at 9:46 PM, Robert Haas <robertmhaas@gmail.com> wrote: > The open items list says this: > > heap_update sets xmax and infomask without logging the changes or > clearing PD_ALL_VISIBLE or visibility map bits > * volunteer owner wanted > * This has been buggy essentially forever but the freeze map changes > give it new urgency. > * Andres working on committing patches > > I believe this issue was fully resolved by > bfa2ab56bb8c512dc8613ee3ff0936568a1c8418. Is that correct? > Regardless, I'd like to extend sincere and heartfelt thanks to Andres > for handling this issue, because I was sure running out of steam (and > time). > > Two other issues were discussed on that thread for which no open > issues were created. First, heap_lock_tuple failed to clear the > all-frozen status. I believe that > eca0f1db14ac92d91d54eca8eeff2d15ccd797fa substantially addressed that > issue and therefore it should be added to the list as a resolved > issue. But, second, as noted in further discussion on that thread and > in the commit message, there is an outstanding theoretical problem > which is non-critical but worthy of being fixed. I recommend we open > a new open issue for that, or at least fix it. > +1. I think, sometime needs to be spend to confirm if that theoretical risk can practically cause any problem. I am planning to spend some time on it in next week or so and will report my observations on that thread. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On 2016-07-22 13:57:15 +0530, Amit Kapila wrote: > On Thu, Jul 21, 2016 at 9:46 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > The open items list says this: > > > > heap_update sets xmax and infomask without logging the changes or > > clearing PD_ALL_VISIBLE or visibility map bits > > * volunteer owner wanted > > * This has been buggy essentially forever but the freeze map changes > > give it new urgency. > > * Andres working on committing patches > > > > I believe this issue was fully resolved by > > bfa2ab56bb8c512dc8613ee3ff0936568a1c8418. Is that correct? Yes, I think so. > > Regardless, I'd like to extend sincere and heartfelt thanks to Andres > > for handling this issue, because I was sure running out of steam (and > > time). You're welcome. > > Two other issues were discussed on that thread for which no open > > issues were created. First, heap_lock_tuple failed to clear the > > all-frozen status. I believe that > > eca0f1db14ac92d91d54eca8eeff2d15ccd797fa substantially addressed that > > issue and therefore it should be added to the list as a resolved > > issue. But, second, as noted in further discussion on that thread and > > in the commit message, there is an outstanding theoretical problem > > which is non-critical but worthy of being fixed. I recommend we open > > a new open issue for that, or at least fix it. > +1. I think, sometime needs to be spend to confirm if that > theoretical risk can practically cause any problem. I am planning to > spend some time on it in next week or so and will report my > observations on that thread. I kind of doubt it's possible for existing users, given that the buffer pretty much will have to be pinned at anything involving high concurrency. That'll prevent cleanup locks concurrently being acquired, before the lock is held. But yea, we should nail that door actually shut. Andres