On Fri, Jun 17, 2016 at 3:36 PM, Noah Misch <n...@leadboat.com> wrote: > I agree the non-atomic, unlogged change is a problem. A related threat > doesn't require a torn page: > > AssignTransactionId() xid=123 > heapam.c:3931 HeapTupleHeaderSetXmax(oldtup.t_data, 123); > some ERROR before heap_update() finishes > rollback; -- xid=123 > some backend flushes the modified page > immediate shutdown > AssignTransactionId() xid=123 > commit; -- xid=123 > > If nothing wrote an xlog record that witnesses xid 123, the cluster can > reassign it after recovery. The failed update is now considered a successful > update, and the row improperly becomes dead. That's important.
I wonder if that was originally supposed to be handled with the HEAP_XMAX_UNLOGGED flag which was removed in 11919160. A comment in the heap WAL logging commit f2bfe8a2 said that tqual routines would see the HEAP_XMAX_UNLOGGED flag in the event of a crash before logging (though I'm not sure if the tqual routines ever actually did that). -- 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
