Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Sure, expression optimization is less aggressive, but is that on its own
>>really going to produce a 100-fold difference in query execution?
>
>
> It's certainly possible, depending on query details.
Andrew pointed out in some offl
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Sure, expression optimization is less aggressive, but is that on its own
> really going to produce a 100-fold difference in query execution?
It's certainly possible, depending on query details. Personally, I
ignored the original report in this thread as
On 2005-07-06, Oliver Jowett <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> The problem is that even with the unnamed statement and deferred planning,
>> the planner still has to treat the parameters as variables, not constants,
>> since nothing in the protocol stops you from running mul
Andrew - Supernews wrote:
> The problem is that even with the unnamed statement and deferred planning,
> the planner still has to treat the parameters as variables, not constants,
> since nothing in the protocol stops you from running multiple portals from
> the unnamed statement. This can make a
On 2005-07-05, Oliver Jowett <[EMAIL PROTECTED]> wrote:
> Ernst Bachmann wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 1753
>> Logged by: Ernst Bachmann
>> Email address: [EMAIL PROTECTED]
>> PostgreSQL version: 8.0.3
>> Operating system: Linux
>> De
-- Forwarded message --
From: jose fuenmayor <[EMAIL PROTECTED]>
Date: Jul 5, 2005 2:27 PM
Subject: problems with pgadmin 3
To: pgsql-admin@postgresql.org
Hi good afternoon everyone, my name is Jose Antonio Fuenmayor Nava, I
am Venezuelan, I work as a Systems Analist in Reingenier
Ernst Bachmann wrote:
> The following bug has been logged online:
>
> Bug reference: 1753
> Logged by: Ernst Bachmann
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.3
> Operating system: Linux
> Description:Query Optimizer does not work well with libpg /
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 10:49:54PM +0200, Hans-Jürgen Schönig wrote:
>> I am running FC4 on x86. There is no core dump.
> Just to be sure: where are you looking? I don't know if it's
> configurable on your platform, but I usually find core dumps under
>
On Tue, Jul 05, 2005 at 10:49:54PM +0200, Hans-Jürgen Schönig wrote:
>
> I am running FC4 on x86. There is no core dump.
Just to be sure: where are you looking? I don't know if it's
configurable on your platform, but I usually find core dumps under
$PGDATA/base//. Do you have a resource limit o
i have never seen this before ...
after rebooting the box (for some other reason) it worked.
somehow there has been something else going terribly wrong ...
sorry for the confusion ...
best regards,
hans
Hans-Jürgen Schönig wrote:
Michael Fuhr wrote:
On Tue, Jul 05, 2
Michael Fuhr wrote:
On Tue, Jul 05, 2005 at 04:37:05PM -0400, Tom Lane wrote:
Michael Fuhr <[EMAIL PROTECTED]> writes:
On Tue, Jul 05, 2005 at 09:54:52PM +0200, Hans-Jürgen Schönig wrote:
we have found a bug in CVS head using PL/Perl:
How current is your checkout? Mine's from this morni
On Tue, Jul 05, 2005 at 04:37:05PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Tue, Jul 05, 2005 at 09:54:52PM +0200, Hans-Jürgen Schönig wrote:
> >> we have found a bug in CVS head using PL/Perl:
>
> > How current is your checkout? Mine's from this morning and I don'
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 09:54:52PM +0200, Hans-Jürgen Schönig wrote:
>> we have found a bug in CVS head using PL/Perl:
> How current is your checkout? Mine's from this morning and I don't
> get a crash with the example you posted:
None for me either (tr
Michael Fuhr wrote:
On Tue, Jul 05, 2005 at 09:54:52PM +0200, Hans-Jürgen Schönig wrote:
we have found a bug in CVS head using PL/Perl:
How current is your checkout? Mine's from this morning and I don't
get a crash with the example you posted:
test=> SELECT func();
NOTICE: sql: SELECT 10,
Thanh Q Lam <[EMAIL PROTECTED]> writes:
> My compiler is gcc 3.2.
I wonder if the problem is that the modified system header files used by
your copy of gcc are too far out of sync with the actual headers under
/usr/include. Michael indicates he's using gcc 3.4.2 which'd presumably
be a lot newer
On Tue, Jul 05, 2005 at 09:54:52PM +0200, Hans-Jürgen Schönig wrote:
>
> we have found a bug in CVS head using PL/Perl:
How current is your checkout? Mine's from this morning and I don't
get a crash with the example you posted:
test=> SELECT func();
NOTICE: sql: SELECT 10, 10 FROM pg_locks WHER
My compiler is gcc 3.2.
Thanks,
Thanh
Michael Fuhr wrote:
On Tue, Jul 05, 2005 at 02:25:07PM -0400, Tom Lane wrote:
Hmm --- the "parse error" suggests that sys/socket.h on your platform
has some inclusion dependency that we are failing to provide for. Can
you find out what it i
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I just ran truss on gcc and noticed that it's reading
> from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/include/sys/types.h
> instead of from /usr/include/sys/types.h. I don't know if that
> matters; I've attached the diff of the two.
Good catch. Th
On Tue, Jul 05, 2005 at 01:46:42PM -0600, Michael Fuhr wrote:
> On Tue, Jul 05, 2005 at 03:27:49PM -0400, Tom Lane wrote:
> > Michael Fuhr <[EMAIL PROTECTED]> writes:
> > > I wonder what's different between Thanh's Solaris 9 box and mine.
> >
> > It would be useful for you guys to compare the resu
Hi Tom/Michael,
To answer Michael's question, I'm trying to install 7.4.8 on Solaris
9. I tried 8.0 which failed at the same problem.
Here is the result of grep from my box:
nsmapp1{postgres}: usr/include> grep projid_t *.h */*.h
nss_dbdefs.h: projid_t projid;
project.h: projid_t
we have found a bug in CVS head using PL/Perl:
[EMAIL PROTECTED] hs]$ psql test < /tmp/core.sql
DROP FUNCTION
CREATE FUNCTION
NOTICE: sql: SELECT 10, 10 FROM pg_locks WHERE transaction IS NOT NULL
AND pid = pg_backend_pid()
server closed the connection unexpectedly
This probably means
Michael Fuhr <[EMAIL PROTECTED]> writes:
> sys/types.h:typedef id_tprojid_t;
Well, we certainly include sys/types.h before including sys/socket.h.
I wonder if the problem is that that typedef is inside an #if that
for some reason is not firing on Thanh's setup?
regards
On Tue, Jul 05, 2005 at 03:27:49PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I wonder what's different between Thanh's Solaris 9 box and mine.
>
> It would be useful for you guys to compare the results of
>
> cd /usr/include
> grep projid_t *.h */*.h
Resul
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 02:25:07PM -0400, Tom Lane wrote:
>> Hmm --- the "parse error" suggests that sys/socket.h on your platform
>> has some inclusion dependency that we are failing to provide for. Can
>> you find out what it is? (Hint: look for "proji
On Tue, Jul 05, 2005 at 02:25:07PM -0400, Tom Lane wrote:
>
> Hmm --- the "parse error" suggests that sys/socket.h on your platform
> has some inclusion dependency that we are failing to provide for. Can
> you find out what it is? (Hint: look for "projid_t")
I wonder what's different between Th
Hi Tom,
Thanks for your quick reply!
I have looked into those system header files, and don't know what
they're for because I'm not a C programmer :-(
Following is the Data block descriptor in the stream.h file that
declares the projid_t.
Thanks again,
Thanh
/*
* Data block descriptor
*
Thanh Q Lam <[EMAIL PROTECTED]> writes:
> when I run: ./configure --without-readline, I get errors that aborts the
> configure process: "checking types of arguments for accept()...
> configure: error: could not determine argument types".
>> In file included from /usr/include/netinet/in.h:41,
>>
Hi,
when I run: ./configure --without-readline, I get errors that aborts the
configure process: "checking types of arguments for accept()...
configure: error: could not determine argument types". Please see
following from the config.log.
Thanks,
Thanh
configure:10983: gcc -c -O2 -fno-s
"Tzahi Fadida" <[EMAIL PROTECTED]> writes:
> If you use C language SPI_execute_plan or SPI_execp it does not release its
> memory usage even after SPI_finish. Usually this is not a problem, but if
> you execute it in your function 100+ times you will feel the difference in
> the form of a memory le
The following bug has been logged online:
Bug reference: 1755
Logged by: Tzahi Fadida
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Linux 2.6.3-7mdk
Description:SPI_execute_plan not releasing memory even after
SPI_finish
Details:
I sub
[EMAIL PROTECTED] (Hans Olav Eggestad) writes:
> I've just installed v8.0.3 and tested the 'epoch' part of extract, which for
> my applications is fundamental. here is the result:
> [ snip ]
Nothing wrong with that that I can see. If you want a date to be
interpreted as midnight GMT rather than m
O Hans Olav Eggestad έγραψε στις Jul 5, 2005 :
> I've just installed v8.0.3 and tested the 'epoch' part of extract, which for
> my applications is fundamental. here is the result:
>
> jova=# select extract(epoch from timestamp '19700102')\g
> date_part
> ---
> 82800
> (1 row)
>
>
I've just installed v8.0.3 and tested the 'epoch' part of extract, which for
my applications is fundamental. here is the result:
jova=# select extract(epoch from timestamp '19700102')\g
date_part
---
82800
(1 row)
jova=# select extract(epoch from timestamp '19700101')\g
date_par
The following bug has been logged online:
Bug reference: 1751
Logged by: Garrett Heaver
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Win2K & WinXP
Description:pg_restore bug
Details:
Hi.
I'm sure you're probably aware of this issue a
The following bug has been logged online:
Bug reference: 1753
Logged by: Ernst Bachmann
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Linux
Description:Query Optimizer does not work well with libpg /
PQexecParams
Details:
It looks like
The following bug has been logged online:
Bug reference: 1752
Logged by: Luis Guevara
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Linux Suxe
Description:Problema al insertar TIME
Details:
Usando el cliente EMS Postgesql ejecuto lo sigu
On Tue, Jul 05, 2005 at 02:06:58PM +0100, Ramzi wrote:
>
> I found a bug in my postgresql which is when I make this select command
> [select * from pg_stat_activity] it doesnt show me active current query, but
> in newer versions and on windows OS it shows the output for this.
> i need a help if i
L.S.
I haven't been able to reproduce this at will, the problem probably depends on
exactly how the trigger being replaced is used at that exact moment, but it
may still be enough info.
db=# select version();
version
--
The following bug has been logged online:
Bug reference: 1754
Logged by: Ramzi
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3
Operating system: Linux
Description:Abou the pg_stat_activity
Details:
hello,
I found a bug in my postgresql which is when I make
39 matches
Mail list logo
