Re: Computing the conflict xid for index page-level-vacuum on primary - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Computing the conflict xid for index page-level-vacuum on primary
Date
Msg-id 20181214184729.3acoji6ljcxsoxqi@alap3.anarazel.de
Whole thread Raw
In response to Re: Computing the conflict xid for index page-level-vacuum on primary  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: Computing the conflict xid for index page-level-vacuum on primary  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
Hi,

On 2018-12-14 21:39:48 +0300, Alexander Korotkov wrote:
> On Fri, Dec 14, 2018 at 4:43 AM Andres Freund <andres@anarazel.de> wrote:
> > This leads me to think that we possibly should move computation of the
> > last removed xid from recovery to the primary, during the generation of
> > the xl_btree_delete WAL record.
> 
> Do I understand correctly that we need this xid computation, because
> we may delete some index tuples using kill_prior_tuple before we prune
> corresponding heap tuples (which would be also replicated and cause
> required conflict)?

Correct.


> If so, then can we just give up with that?  That is before setting
> kill_prior_tuple = true, prune corresponding heap tuples.

That'd require WAL logging such changes, which'd be pretty bad, because
we'd need to do it one-by-one.  What we could do, and what I suggested
earlier, is that we do a bit more pruning when emitting such WAL
records.


Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: removal of dangling temp tables
Next
From: Tom Lane
Date:
Subject: Re: Ryu floating point output patch