Re: preserving forensic information when we freeze - Mailing list pgsql-hackers

From Andres Freund
Subject Re: preserving forensic information when we freeze
Date
Msg-id 20130624121234.GD6471@awork2.anarazel.de
Whole thread Raw
In response to preserving forensic information when we freeze  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: preserving forensic information when we freeze
List pgsql-hackers
On 2013-05-28 09:21:27 -0400, Robert Haas wrote:
> As a general statement, I view this work as something that is likely
> needed no matter which one of the "remove freezing" approaches that
> have been proposed we choose to adopt.  It does not fix anything in
> and of itself, but it (hopefully) removes an objection to the entire
> line of inquiry.

Agreed. And it also improves the status quo when debugging. I wish this
would have been the representation since the beginning.

Some remarks:
* I don't really like that HeapTupleHeaderXminFrozen() now is frequently performed without checking for
FrozenTransactionId.I think the places where that's done are currently safe, but it seems likely that we introduce bugs
dueto people writing similar code. I think replacing *GetXmin by a wrapper that returns FrozenTransactionId if the hint
bittell us so would be a good idea. Then add *GetRawXmin for the rest (probably mostly display). Seems like it would
makethe patch actually smaller.
 

* The PLs imo should set fn_xmin to FrozenTransactionId if the hint bit tell us the tuple is frozen.

* I think rewrite_heap_dead_tuple needs to check for a frozen xmin and store that. We might looking at a chain which
partiallywas done in <9.4. Not sure if that's a realistic scenario, but I'd rather be safe.
 

Otherwise I don't see much that needs to be done before this can get
committed.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Alexander Law
Date:
Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console
Next
From: Andrew Dunstan
Date:
Subject: Re: [9.4 CF 1] The Commitfest Slacker List