On Sun, Aug 05, 2007 at 02:08:38AM +, Lamia Jackson wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3514
> Logged by: Lamia Jackson
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4.1
> Operating system: win32
> Description:bug
Brodie Thiesfield wrote:
> The database is created in UTF-8.
> CREATE DATABASE crossbase WITH OWNER = tserver ENCODING = 'UTF-8';
>
> postgres=# \l
>List of databases
> Name| Owner | Encoding
> ---+--+--
> crossbase | tserver | UTF8
> crosstest | postgre
The following bug has been logged online:
Bug reference: 3514
Logged by: Lamia Jackson
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4.1
Operating system: win32
Description:buggy install + no manual support (add)
Details:
Installation completes w/o except
The database is created in UTF-8.
CREATE DATABASE crossbase WITH OWNER = tserver ENCODING = 'UTF-8';
postgres=# \l
List of databases
Name| Owner | Encoding
---+--+--
crossbase | tserver | UTF8
crosstest | postgres | UTF8
postgres | postgres | UTF8
temp
Thanks Tom,
By setting from_collapse_limit to more than 10, the query takes 133ms instead
of 20s.
My question is: why even if from_collapse_limit is set to 8 (it's default
value), the same query takes 30ms just by changing the order of PRPT_PRT and
PROR_ORG tables in the query?
-Message d'
I've played with both parameters but it doesn't help in this case
Thanks
-Message d'origine-
De : Heikki Linnakangas [mailto:[EMAIL PROTECTED] De la part de Heikki
Linnakangas
Envoyé : 6 août 2007 16:58
À : Mouhamadou Dia
Cc : pgsql-bugs@postgresql.org
Objet : Re: RE : RE : [BUGS] BUG #3
"Rajaram J" <[EMAIL PROTECTED]> writes:
> I'm having trouble building 64-bit pgsql 7.4.17 on the latest release of =
> HP-UX 11.23 on ia64.
We only started supporting that platform combination in 8.0.
regards, tom lane
---(end of broadcast)
Ravikumar wrote:
> Hi, I have got this new error while executing my application which is in
> vb.net.
This is the relevant piece of information in the stack trace:
> ERROR: relation "t_localisation" does not exist
Apparently that table doesn't exist.
--
Heikki Linnakangas
EnterpriseDB
The following bug has been logged online:
Bug reference: 3521
Logged by: Ravikumar
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest Version
Operating system: Win 2003
Description:ExecuteCommandTextForSingleResult : Fatal error in query
Details:
Hi, I have
On Tue, Aug 07, 2007 at 03:41:07AM +, Brodie Thiesfield wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3520
> Logged by: Brodie Thiesfield
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system: Windows XP SP2
> Descript
"Brodie Thiesfield" <[EMAIL PROTECTED]> writes:
> (at time of final INSERT)
> ERROR: XX000: invalid memory alloc request size 2147483648
> LOCATION: MemoryContextAlloc, mcxt.c:504
Some questions: what encoding was the database created in? And what locale is
your server running in?
The command
It seems that TAS(mutex) is not supported. Try to compile with
--disable-spinlocks, but performance will not be good.
I'm not sure if this file is in 7.4 version, but see
pgsql/src/backend/port/hpux/tas.c.template
Zdenek
Rajaram J wrote:
Hi
I'm having trouble building 64-b
Hi
I'm having trouble building 64-bit pgsql 7.4.17 on the latest release of HP-UX
11.23 on ia64.
Here's my compiler:
cc: HP C/aC++ B3910B A.06.15 [May 16 2007]
Here's my error:
/opt/ansic/bin/cc -Ae +O2 -L../../src/port -Wl,+nodefaultrpath -L/usr/lib
-L/opt/openssl/lib -Wl,+b -Wl,/opt/rajara
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The structure of your query is a whole series of left outer joins, the result
>> of which is then (inner) joined with one more table. The outer joins return a
>> whole lot of records but the inner join is only go
The following bug has been logged online:
Bug reference: 3520
Logged by: Brodie Thiesfield
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows XP SP2
Description:insert causing error "invalid memory alloc request size
2147483648"
Detai
I'm sending in attachment the output of the explain analyze command and the
create table statements of tables involved in the query.
Yes, I have vacuumed and analyzed my database this morning before running the
query.
I'm sorry; I thought it was a bug with the optimizer, that's why I used the
r
Not quite, here's what happens every second when idling, for both good and
bad connections (with a different values to each syscall). It is trying to
read data, I am a little concerned about the EAGAIN return value, though.
[EMAIL PROTECTED] ~ $ strace -p 6987
poll([{fd=3, events=POLLIN}, {fd=4, e
Here's what the primary maintainer of the app had to say about how notifies
get read.
This is in update_reqs in Gtkreq, which gets called by a Gtk timer
every second. Then, as long as there are notifies, it will
continue to read from the req log.
There's a timer for every instance of the main wi
Sorry,
This output is coming from PG 8.1.19
I'm attaching the one that is coming from 8.2.4
Thanks and sorry for the confusion
-Message d'origine-
De : Heikki Linnakangas [mailto:[EMAIL PROTECTED] De la part de Heikki
Linnakangas
Envoyé : 6 août 2007 15:32
À : Mouhamadou Dia
Cc : pgsql-b
19 matches
Mail list logo
