From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Subject: | Re: Computing the conflict xid for index page-level-vacuum on primary |
Date: | 2018-12-16 03:29:39 |
Message-ID: | CAPpHfdvAj3Jz7goZu-y-=0WQBbFi1rGjjoTLF3cj1vPpsjURZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 14, 2018 at 9:47 PM Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2018-12-16 05:17:35 | select limit error in file_fdw |
Previous Message | Thomas Munro | 2018-12-16 02:26:20 | Re: BUG #15548: Unaccent does not remove combining diacritical characters |