Re: [PATCH] Negative Transition Aggregate Functions (WIP)

From: "Erik Rijkers" <er(at)xs4all(dot)nl>
To: "David Rowley" <dgrowleyml(at)gmail(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date: 2013-12-25 15:09:05
Message-ID: d06c97a1312bbc85fcfb9aaa39c3ee28.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, December 25, 2013 14:49, David Rowley wrote:

> [ inverse_transition_functions_v1.5.patch.gz ]

I ran into the following problem which is, I think, NOT a problem with your patch but with my setup. Still, if anyone can
enlighten me on its cause I'd be thankful (it shows up every now and then for me).

I have a 200 GB dev database running under 9.4devel that I thought I could now, for test purposes, compile a patched
postgres binary for (i.e.: a HEAD + inverse_transition_functions_v1.5.patch.gz binary), so as to avoid an initdb and use
the existing 200 GB data.

I know the patch is valid, because a separately built, newly initdb-ed instance runs the below statement without fail.

But running from existing 200 gb dev database I get:

$ echo "\\set VERBOSITY verbose \\\\ SELECT SUM(n::integer) OVER (ORDER BY n ROWS BETWEEN CURRENT ROW AND UNBOUNDED
FOLLOWING) FROM generate_series(1, 100) g(n)" | psql
ERROR: XX000: cache lookup failed for type 0
LOCATION: get_typlenbyval, lsyscache.c:1895
Time: 2.752 ms

Is there a way I can use the existing database and avoid both initdb and this error?

Thanks,

Erik Rijkers

See also:
[1]
http://www.postgresql.org/message-id/flat/E5F4C5A18CAB7A4DA23080DE9CE8158603E67AA1(at)eaubrmw001(dot)eapac(dot)ericsson(dot)se#E5F4C5A18CAB7A4DA23080DE9CE8158603E67AA1@eaubrmw001.eapac.ericsson.se

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-12-25 16:49:56 Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Previous Message Oleg Bartunov 2013-12-25 14:44:17 Re: [BUG FIX] Version number expressed in octal form by mistake