The following bug has been logged on the website:
Bug reference: 8143
Logged by: Joel Roller
Email address: jrol...@rjobrien.com
PostgreSQL version: 9.2.4
Operating system: Debian 6.0.7 + squeeze-pgdg
Description:
Howdy.
We've come across a specific query and query p
Whilst working on a build issue with pl/python, I noticed an
inconsistency in the way the server reacts to attempts to use PLs for
which the interpreter doesn't exist. Not sure how feasible it would be
to fix this, but the Python case doesn't seem ideal:
psql.bin (9.3beta1)
Type "help" for help.
jrol...@rjobrien.com writes:
> We've come across a specific query and query plan that causes a repeatable
> segmentation fault on the postgresql backend.
Ah, I see it: gistrescan() is trying to preserve the per-scankey
fn_extra values to allow caching, but what it's doing does not work
if more tha
The following bug has been logged on the website:
Bug reference: 8144
Logged by: Marc Munro
Email address: m...@bloodnok.com
PostgreSQL version: 9.2.4
Operating system: Linux 3.6.3 (debian wheezy)
Description:
I have a query in which I want to use the result of a wind
On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund wrote:
> The attached patch fixes this although I don't like the way it knowledge of
> the
> point up to which StartupSUBTRANS zeroes pages is handled.
One month has passed since the patched version was installed in our
production environment and ca
m...@bloodnok.com writes:
> I have a query in which I want to use the result of a window function to
> isolate the most relevant results. While I was trying to develop and test
> the query, I discovered what looks like a bug in the results of the rank()
> function. This has been tried with the s
