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 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 committed. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
