On Tue, Jun 21, 2016 at 9:16 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > Some others ways could be: > > > > Before releasing the lock on buffer containing old tuple, clear the VM and > > visibility info from page and WAL log it. I think this could impact > > performance depending on how frequently we need to perform this action. > > > > Have a new flag like HEAP_XMAX_UNLOGGED (as it was there when this logic was > > introduced in commit f2bfe8a24c46133f81e188653a127f939eb33c4a ) and set the > > same in old tuple header before releasing lock on buffer and teach tqual.c > > to honor the flag. I think tqual.c should consider HEAP_XMAX_UNLOGGED as > > an indication of aborted transaction unless it is currently in-progress. > > Also, I think we need to clear this flag before WAL logging in heap_update. > > I also noticed that and wondered whether it was a mistake to take that > out. It appears to have been removed as part of the logic to clear > away UNDO log support in 11919160, but it may have been an important > part of the heap_update protocol. Though (as I mentioned nearby in a > reply to Noah) it I'm not sure if the tqual.c side which would ignore > the unlogged xmax in the event of a badly timed crash was ever > implemented. >
Right, my observation is similar to yours and that's what I am suggesting as one-alternative to fix this issue. I think making this approach work (even if this doesn't have any problems) might turn out to be tricky. However, the plus-point of this approach seems to be that it shouldn't impact performance in most of the cases.
