Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pavel Hanák <hanak(at)is-it(dot)eu>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Date: 2016-11-03 23:24:39
Message-ID: CAB7nPqRsLqTWM4VgcurYxOHsUdHX-GJoyW+XWXu=Ztqccv4E_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Nov 3, 2016 at 2:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After further poking around, I concluded that it'd be a good idea to make
> a similar change in set_dummy_tlist_references(), to prevent a failure
> if the top plan node below ModifyTable chances to be a Sort or other
> non-projecting plan node. I'm not sure such a case can arise today, but
> I'm not sure it can't either.

[ ... Back on this thread ... ]
Thanks for the input! It would have taken waaay longer to me to figure
out a clean patch. I am not very familiar with this code :)

> I'm not sure if it's worth memorializing the specific test case discussed
> in this thread as a regression test. It depends enough on the behavior
> of SQL function planning that I wouldn't have much confidence in it
> continuing to test what we meant it to test going forward.

Definitely fine to not include it for me, the regression tests
modified by your patch and the git history are enough to understand
the story of the fix.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2016-11-03 23:26:39 Re: BUG #14410: Restoring data not successful
Previous Message Kevin Grittner 2016-11-03 22:52:16 Re: BUG #14411: Issue with using OFFSET