On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila <amit.kapil...@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. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
