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
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 |