On 23 January 2016 at 09:44, David Rowley <david.rowley@2ndquadrant.com> wrote:
> On 23 January 2016 at 09:17, Jeff Janes <jeff.janes@gmail.com> wrote:
>> On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley
>>> <david.rowley@2ndquadrant.com> wrote:
>>>> Agreed. So I've attached a version of the patch which does not have any of
>>>> the serialise/deserialise stuff in it.
>>>
>>> I re-reviewed this and have committed most of it with only minor
>>> kibitizing. A few notes:
>>
>>
>> This commit has broken pg_dump. At least, I think this is the thread
>> referencing this commit:
>>
> ...
>> pg_dump: column number -1 is out of range 0..17
>> Segmentation fault (core dumped)
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x0000000000416b0b in dumpAgg (fout=0x1e551e0, agginfo=0x1e65ec0)
>> at pg_dump.c:12670
>> 12670 if (strcmp(aggcombinefn, "-") != 0)
>> (gdb) bt
>> #0 0x0000000000416b0b in dumpAgg (fout=0x1e551e0, agginfo=0x1e65ec0)
>> at pg_dump.c:12670
>> #1 0x000000000041df7a in main (argc=<value optimized out>,
>> argv=<value optimized out>) at pg_dump.c:810
>
> Yikes :-( I will look at this with priority in the next few hours.
>
> Thanks for the report.
It seems that I must have mistakenly believed that non-existing
columns for previous versions were handled using the power of magic.
Turns out that I was wrong, and they need to be included as dummy
columns in the queries for previous versions.
The attached fixes the problem.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
