The following bug has been logged on the website:
Bug reference: 8469
Logged by: Dennis
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: 9.3.0
Operating system: FreeBSD 9.2-RC4
Description:
Hi,
After upgrading an 8.1 version to 9.3.0 I am suddenly seei
> Linking pthreads into the backend is likely to cause more problems than
> it solves, especially if you're proposing that we do that everywhere.
>
> regards, tom lane
No, I am not proposing that. Not linking to pthread when not needed should
actually be an
optimization sin
After a few hours of watching strange things happening I finally stumbled
on the cause.
Very short summary: the postgres binary needs to be linked to libpthread,
as this will ensure a special fork() inside libthr (the FreeBSD libpthread
implementation/wrapper) is used which correctly deals with a
> Any idea what query triggered this?
Only up to which stored procedure (which itself contains multiple
statements).
However, in a new fresh FreeBSD environment (under virtualbox) I can
trigger a similar (my guess is it is the same issue) segmentation fault
reliably.
Application is a Python we
The following bug has been logged online:
Bug reference: 4814
Logged by: Dennis Noordsij
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: 8.4 SNAP 17MAY
Operating system: Linux
Description:Segmentation fault when using indexed prefix FT search
Details
On Tuesday 05 May 2009 17:16:03 Tom Lane wrote:
> "Dennis Noordsij" writes:
> > (gdb) bt
> > #0 0x004eecf7 in compute_scalar_stats (stats=0x1abd878,
> > fetchfunc=0x4f0f30 , samplerows= > out>, totalrows=4154315)
> > at analyze.c:232
The following bug has been logged online:
Bug reference: 4793
Logged by: Dennis Noordsij
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: snapshot/beta1
Operating system: 64bit arch Linux
Description:Segmentation fault when doing vacuum analyze
Details
