|From:||Andres Freund <andres(at)2ndquadrant(dot)com>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: preserving forensic information when we freeze|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
* 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 due to people writing similar code.
I think replacing *GetXmin by a wrapper that returns
FrozenTransactionId if the hint bit tell us so would be a good
idea. Then add *GetRawXmin for the rest (probably mostly display).
Seems like it would make the 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 partially was 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
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Andrew Dunstan||2013-06-24 12:13:14||Re: [9.4 CF 1] The Commitfest Slacker List|
|Previous Message||Alexander Law||2013-06-24 12:00:00||Re: BUG #7493: Postmaster messages unreadable in a Windows console|