Re: Old row version in hot chain become visible after a freeze

Wood, Dan <hexpert@amazon.com>

From: "Wood, Dan" <hexpert@amazon.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: "pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Date: 2017-08-31T23:20:04Z
Lists: pgsql-bugs
I was aware of the other one and, in fact, reverted the change just to make sure it wasn’t Involved.  A strange coincidence indeed.

On 8/31/17, 3:57 PM, "Peter Geoghegan" <pg@bowt.ie> wrote:

    Hi Dan,
    
    Nice to hear from you.
    
    On Thu, Aug 31, 2017 at 3:36 PM, Wood, Dan <hexpert@amazon.com> wrote:
    > Because tupgone is false we freeze instead of deleting.  Freezing a DEAD
    > tuple makes it visible.  Here is a comment in heap_prepare_freeze_tuple()
    >
    >
    >
    >   * It is assumed that the caller has checked the tuple with
    >
    >   * HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
    
    Funny that there'd be another bug associated with
    heap_prepare_freeze_tuple() so soon after the last one was discovered.
    Are you aware of the other one [1]?
    
    BTW, I just posted a patch to enhance amcheck, to allow it to verify
    that an index has all the entries that it ought to [2]. Perhaps you'd
    find it useful for this kind of thing. I welcome your feedback on
    that.
    
    [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=31b8db8e6c1fa4436116f4be5ca789f3a01b9ebf;hp=f1dae097f2945ffcb59a9f236843e0e0bbf0920d
    [2] https://commitfest.postgresql.org/14/1263/
    -- 
    Peter Geoghegan
    


Commits

  1. Fix freezing of a dead HOT-updated tuple

  2. Fix potential data corruption during freeze

  3. Clarify the contract of partition_rbound_cmp().