Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Reviewing freeze map code
Date
Msg-id CAEepm=1hgCCz1PZyhuPj0=ybsq601QotQbaOA=skqsaMMO5ARQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviewing freeze map code  (Noah Misch <noah@leadboat.com>)
Responses Re: Reviewing freeze map code  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Fri, Jun 17, 2016 at 3:36 PM, Noah Misch <noah@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: parallel.c is not marked as test covered
Next
From: Alvaro Herrera
Date:
Subject: Re: parallel.c is not marked as test covered