I observe the following issue on PostgreSQL 9.0.4 on at least the
following platforms:
* FreeBSD 6.3 (amd64)
`uname -a`:
FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE #1: Fri May 30 18:11:47
PDT 2008
root@:/data/obj/data/home//symbols/builddir_amd64/usr/src/sys/MESSAGING_GATEWAY.amd64_I
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, July 26, 2011 7:42 PM
To: David Johnston
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6131: Query Returning Incorrect Results
"David Johnston" writes:
> The embedded script exhibits some strange beh
"David Johnston" writes:
> The embedded script exhibits some strange behavior. When the query is run
> the [adjustment_paid] column for [technician] "6338B" should show +/- 25.00.
> Instead, if I run the last query immediately after creating the schema and
> inserting the data the results I get
> 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
The following bug has been logged online:
Bug reference: 6131
Logged by: David Johnston
Email address: pol...@yahoo.com
PostgreSQL version: 9.0.4
Operating system: Windows 7 64-bit
Description:Query Returning Incorrect Results
Details:
The embedded script exhibits s
Just a follow up on this bug. After further checking.. some of the data did
not load, but it was able to continue restoring. (looks like it skipped the
bad records?)
The interesting thing.. after I discovered the missing data. I dumped just
those three tables(form_config, form_field_config, form_b
noordsij writes:
> 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 w
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
"Arne Scheffer" wrote:
> Sorry, missed to fill out this form, please see
>
> http://archives.postgresql.org/pgsql-bugs/2011-07/msg00172.php
As mentioned in the reply to that post, this is not a bug.
You can wait for autovacuum to fix things up, or run VACUUM ANALYZE
against the database. I
The following bug has been logged online:
Bug reference: 6130
Logged by: Arne Scheffer
Email address: bteam...@uni-muenster.de
PostgreSQL version: 9.0.4
Operating system: RHEL 5.6
Description:TOAST tables bug restoring to PostgreSQL 9.0.4
Details:
Sorry, missed to f
10 matches
Mail list logo