Re: [HACKERS] pgsql: Fix freezing of a dead HOT-updated tuple

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "Wood, Dan" <hexpert(at)amazon(dot)com>, pgsql-committers(at)postgresql(dot)org, "Wong, Yi Wen" <yiwong(at)amazon(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] pgsql: Fix freezing of a dead HOT-updated tuple
Date: 2017-11-03 19:36:59
Message-ID: 20171103193659.GA3404@marmot
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> wrote:
>Here's that patch. I've stared at this some, and Robert did too. Robert
>mentioned that the commit message might need some polish and I'm not
>100% sure about the error message texts yet.

The commit message should probably say that the bug involves the
resurrection of previously dead tuples, which is different to there
being duplicates because a constraint is not enforced because HOT chains
are broken (that's a separate, arguably less serious problem).

>Staring at the vacuumlazy hunk I think I might have found a related bug:
>heap_update_tuple() just copies the old xmax to the new tuple's xmax if
>a multixact and still running. It does so without verifying liveliness
>of members. Isn't that buggy? Consider what happens if we have three
>blocks: 1 has free space, two is being vacuumed and is locked, three is
>full and has a tuple that's key share locked by a live tuple and is
>updated by a dead xmax from before the xmin horizon. In that case afaict
>the multi will be copied from the third page to the first one. Which is
>quite bad, because vacuum already processed it, and we'll set
>relfrozenxid accordingly. I hope I'm missing something here?

Can you be more specific about what you mean here? I think that I
understand where you're going with this, but I'm not sure.

Peter Geoghegan

In response to


Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2017-11-03 19:52:04 Re: [HACKERS] pgsql: Fix freezing of a dead HOT-updated tuple
Previous Message Alvaro Herrera 2017-11-03 18:52:25 Re: pgsql: Fix BRIN summarization concurrent with extension

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-11-03 19:38:54 Re: ucs_wcwidth vintage
Previous Message Tom Lane 2017-11-03 19:30:25 Re: Small improvement to compactify_tuples