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

From Alexander Korotkov
Subject Re: Computing the conflict xid for index page-level-vacuum on primary
Date
Msg-id CAPpHfdvAj3Jz7goZu-y-=0WQBbFi1rGjjoTLF3cj1vPpsjURZQ@mail.gmail.com
Whole thread Raw
In response to Re: Computing the conflict xid for index page-level-vacuum on primary  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Dec 14, 2018 at 9:47 PM Andres Freund <andres@anarazel.de> wrote:
> On 2018-12-14 21:39:48 +0300, Alexander Korotkov wrote:
> > 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.

It's not necessary one-by-one, we could decide to prune the whole heap
page and eventually delete more tuples.  But yes, in worst case it
would be one-by-one.  I'm not sure what would be practical average
value.

Also, for resolving conflicts we only need to inform standby about
latest removed xid.  So, before setting kill_prior_tuple = true, we
might emit WAL record with just latest removed xid, but only if it's
greater than latest removed xid written to the WAL previously.  So, in
worst case it would be one extra WAL record per transaction, but
hopefully it would be much less.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 'infinity'::Interval should be added
Next
From: Erik Rijkers
Date:
Subject: select limit error in file_fdw