On Fri, Dec 14, 2018 at 9:47 PM Andres Freund 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 b
On Thu, Dec 13, 2018 at 5:42 PM Andres Freund 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.
For the record, I share your sense that this isn't a great desi
Hi,
On 2018-12-14 21:39:48 +0300, Alexander Korotkov wrote:
> On Fri, Dec 14, 2018 at 4:43 AM Andres Freund 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 rec
On Fri, Dec 14, 2018 at 4:43 AM Andres Freund 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, be
Hi,
Currently nbtree and hash indexes (and soon gist, where it's missing due
to oversight) compute an xid that is used to resolve recovery conflicts.
They do so by visiting all the heap pages
xl_btree_delete/xl_hash_vacuum_one_page point to item-by-item.
That's problematic for two projects I'm wo
