[BUGS] Bug #715: Too much memory consuming with postmaster
Milan Hromada ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
Too much memory consuming with postmaster
Long Description
Big diffrence in performence between 7.1 and 7.2.1. In 7.2.1 postmaster grows up to
700 MB RAM and more while in 7.1 just up to 8 MB RAM.
7.1 has better response on 1.4 Ghz Athlon 256MB RAM then 7.2.1 on Dual 1GHz Intel
Pentium III with 1GB RAM. Postmaster cousumes all resoureces
Sample Code
CREATE VIEW "faksluexport" AS SELECT "zakazkaoprava"."id_zakazka" as idzakazka,
"cisopravaceny"."cena_bezdph" as p_cena,
"cisopravaceny"."cena" as p_cena_c,"cisopravaceny"."kdph" as kdph,
"zakazka"."id_cispobocka" as pobocka, "cispobocka"."stredisko" as
stredisko,"cisoprava"."popis" as
+snaz,
"cisdealer"."snaz" as snazo,"cisfakt"."ico" as ico,"cisfakt"."cislo_uctu" as
cbu,"zakazka"."cislo" as
+zakazka,"cisbanka"."kod" as skb,"cisvyrobca"."znacka" as znacka,
"zakazka"."id_ciszaruka" as zaruka,
"zakazkauct"."storno" as storno
FROM "cisoprava","zakazkaoprava","cisopravaceny","cisdealer", "zakazka", "cisfakt",
+"zakazkauct","cispobocka","cisbanka","cisvyrobca","cismtop","cismttyp"
WHERE "zakazkaoprava"."id_cisoprava"="cisoprava"."id_cisoprava" AND
"cisoprava"."id_cisoprava"="cismtop"."id_cisoprava"
AND "cismtop"."id_cismtop"="cisopravaceny"."id_cismtop"
AND "cisfakt"."id_cisbanka"="cisbanka"."id_cisbanka"
AND "zakazka"."id_zakazka"="zakazkaoprava"."id_zakazka"
AND "cisopravaceny"."platnost_od"<="zakazka"."d_prijem"
AND ("cisopravaceny"."platnost_do">"zakazka"."d_prijem" OR
"cisopravaceny"."platnost_do" IS NULL)
AND "cismtop"."id_cismttyp"="zakazka"."id_cismttyp"
AND "cismtop"."id_cismttyp"="cismttyp"."id_cismttyp"
AND "cisvyrobca"."id_cisvyrobca"="cismttyp"."id_cisvyrobca"
AND "zakazka"."id_zakazka"="zakazkauct"."id_zakazka" AND
+"zakazka"."id_cisdealer"="cisdealer"."id_cisdealer"
AND "cisfakt"."id_cisfakt"="cisdealer"."id_cisfakt" AND "zakazkauct"."d_export"='1'
AND "zakazkauct"."typ_platby"='0'
AND "zakazka"."id_cispobocka"="cispobocka"."id_cispobocka"
ORDER BY idzakazka,p_cena DESC;
No file was uploaded with this report
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] initdb problem
Hi! I don't know if it is a bug or not. What I am facing is that I can't open a database I created. It's better to explain you by below scenario: I have installed the Postgres v7.1 or later. Then, I changed the initial database cluster to another disk, "/mydb". Then, I changed "PGDATA" in the "/etc/rc.d/init.d/postgresql". I did change all "start", and "stop" PGDATA variable to "/mydb". Everything works fine. Until I formated the Linux (Redhat, v7.1) system, and re-installed the Redhat (v7.1) again. Please note that "/mydb" is not been removed because it is kept in another disk. Now I installed the Postgres v7.1 again, and try to changed the initial database cluster to "/mydb". And it cannot allow me to do that. My point is how can I open my database I kept in "/mydb" again. Is it a bug? Please help me. Sincerely yours, --Ping - Nattaphol Manomaiphan. EVSD Project LeaderNo Magic Asia Ltd., 719, 22nd Fl., KPN Tower, Rama IX Road, Huaykwang, Bangkok 10320 Thailand.Phone: +66-2-7170252 Fax: +66-2-7170251email: [EMAIL PROTECTED]http://www.nomagicasia.com
[BUGS] pg_ctl failure with older Bourne shells (use ${1:+"$@"})
Your name : Mike Coleman
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) :alpha
Operating System (example: Linux 2.0.26 ELF) :Tru64 5.1
PostgreSQL version (example: PostgreSQL-7.2.1): PostgreSQL-7.2.1
Compiler used (example: gcc 2.95.2) :gcc 3.1
Please enter a FULL description of your problem:
The pg_ctl script uses the "$@" construct. Newer shells will replace
this with nothing if $@ is empty, but older shells will not. The
alternate form in the patch below will work for both new and old
shells.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
The problem occurs with this command, for example:
$ /usr/local/pgsql/bin/pg_ctl -D /data1/postgres-0 -l logfile start
If you know how this problem might be fixed, list the solution below:
-
--- /usr/local/pgsql/bin/pg_ctl.dist2002-07-18 11:34:25.0 -0500
+++ /usr/local/pgsql/bin/pg_ctl 2002-07-18 14:44:35.0 -0500
@@ -332,12 +332,12 @@
fi
if [ -n "$logfile" ]; then
-"$po_path" "$@" >$logfile 2>&1 &
+"$po_path" ${1:+"$@"} >$logfile 2>&1 &
else
# when starting without log file, redirect stderr to stdout, so
# pg_ctl can be invoked with >$logfile and still have pg_ctl's
# stderr on the terminal.
-"$po_path" "$@" &1 &
+"$po_path" ${1:+"$@"} &1 &
fi
# if had an old lockfile, check to see if we were able to start
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug #716: No index usage for "WHERE a IN ( SELECT ...)"
Janko Richter ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description No index usage for "WHERE a IN ( SELECT ...)" Long Description I have created a table "testtab" with an unique indexed (smallint) column "a" and 10.000 records. When I do "EXPLAIN SELECT * FROM testtab WHERE a IN ( 12::smallint )" Postgresql 7.2.1 gives : Index Scan using uhu2idx on testtab (cost=0.00..3.01 rows=1 width=2) But when I'm using a subquery i.e.: "EXPLAIN SELECT * FROM testtab WHERE a IN ( SELECT 12::smallint )" PG gives: Seq Scan on testtab (cost=0.00..275.00 rows=5000 width=2) SubPlan -> Materialize (cost=0.01..0.01 rows=1 width=0) -> Result (cost=0.00..0.01 rows=1 width=0) The subquery is an example for a subquery result set. With "real" subquerys PG does a seq scan too.Of course, in some situations this bug (?) makes the queries extremly slow. Regards , Janko Richter Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #714: pg_dump segfaults when given an invalid command
Sorry but I'm using 7.2.1 and am seeing the problem :). It didn't occur on the same machine/libs with 7.1.2. Regards, Menno Smits On Thu, Jul 18, 2002 at 11:00:58PM -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I just tried with current CVS and got: > > $ aspg pg_dump --someoptionthatdoesntexist somedb > > pg_dump: unrecognized option `--someoptionthatdoesntexist' > > Try 'pg_dump --help' for more information. > > My guess is that there is something buggy with your libc getopt. Can > > someone else reproduce this error? > > This is fixed since 7.2. > > regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
