Re: problem with RETURNING and update row movement

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: problem with RETURNING and update row movement
Date: 2020-09-30 03:34:17
Message-ID: CA+HiwqHTxzx+aHU+cvkzm8cjXvEK9K-G6b8UoTm2Sx0ADVQeFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 24, 2020 at 2:26 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Sep 24, 2020 at 1:54 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > On Thu, Sep 24, 2020 at 04:25:24AM +0900, Etsuro Fujita wrote:
> > > Sorry, my thought was vague. To store xmin/xmax/cmin/cmax into a
> > > given slot, we need to extend the TupleTableSlot struct to contain
> > > these attributes as well? Or we need to introduce a new callback
> > > routine for that (say, setsysattr)? These would not be
> > > back-patchable, though.
> >
> > Please note that the latest patch fails to apply, so this needs a
> > rebase.
>
> I saw the CF-bot failure too yesterday, although it seems that it's
> because the bot is trying to apply the patch version meant for v11
> branch onto HEAD branch. I just checked that the patches apply
> cleanly to their respective branches.

I checked that the last statement is still true, so I've switched the
status back to Needs Review.

--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2020-09-30 03:38:50 Re: NOTIFY docs fixup - emit and deliver consistency
Previous Message osumi.takamichi@fujitsu.com 2020-09-30 03:10:53 RE: Disable WAL logging to speed up data loading