[BUGS] "VIRUS found in:" Re: That movie
See the attached file for detailsTitle: VIRUS INFECTION ALERT VIRUS INFECTION ALERT A virus was detected in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: thank_you.pif Virus name: W32/[EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Returned due to virus; Was: Re: Thank you!
Please see the attached file for details.<<< Text/HTML; name="details.pif.htm": Unrecognized >>> ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] [INTERFACES] ECPG Connect user :variable problem
Sorry about that last patch, I hit the wrong one (my bison is
way out of date, so I'm hacking the resulting .c file for test
and backporting to the .y file, not that thats an excuse :)
Anyway here is a patch to 7.4b1 that seems to apply to the snap
from yesterday as well.
This allows you to
EXEC SQL CONNECT TO :target as :connection_name user :uname using :password;
and have the uname and password C variables get passed correctly to the
ECPGconnect fucntion after epgc processing.
On Tue, Aug 19, 2003 at 12:17:08PM -1000, Ryan Mooney wrote:
>
> Hello,
>
> I'm having a major problem using ecpg with 7.4beta1. The problem is that
> if I try to pass in the username or password as :variables to the EXEC SQL
> CONNECT code they are essentially ignored (replaced by " ?").
>
> I've tried it on both redhat 7.2 IA64 and Redhat 9.0 IA32 (different enough
> that I don't think its the platform). I also tried it with postgres 7.3.2
> which seemed to do the "right thing" and put the variables into the ECPGconnect
> call.
>
> Any thoughts?
>
> ---
> int pg_connect(void)
> {
>
> EXEC SQL BEGIN DECLARE SECTION;
> char *target = "dbname";
> char *connection_name = "myconnection";
> char *uname = "myuser";
> char *password = "mypassword";
> EXEC SQL END DECLARE SECTION;
>
> EXEC SQL CONNECT TO :target as :connection_name user :uname using :password;
>
> }
>
> ---
>
> int pg_connect(void)
> {
>
> /* exec sql begin declare section */
>
>
>
>
>
> #line 5 "connect.pgc"
> char * target = "dbname" ;
>
> #line 6 "connect.pgc"
> char * connection_name = "myconnection" ;
>
> #line 7 "connect.pgc"
> char * uname = "myuser" ;
>
> #line 8 "connect.pgc"
> char * password = "mypassword" ;
> /* exec sql end declare section */
> #line 9 "connect.pgc"
>
>
> { ECPGconnect(__LINE__, 0, target , " ?" , " ?" , connection_name, 0); }
> #line 11 "connect.pgc"
>
>
> }
>
>
> --
> >-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-<
> Ryan Mooney[EMAIL PROTECTED]
> <-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=->
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
--
>-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-<
Ryan Mooney [EMAIL PROTECTED]
<-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=->
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] index not used afer VACUUM ANALYZE
Hi, I should state that I use 7.4beta1 under FreeBSD -current. On Thu, 21 Aug 2003, mike wrote: > Date: Thu, 21 Aug 2003 18:28:53 +0200 (CEST) > From: mike <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: index not used afer VACUUM ANALYZE > > Hi, > I hav a db as specified in nit.sql > flows has 763488 entries. > > After dropping/creating/loading the db and running auswert.sh I get > the attached result from query1.txt. > After 'VACUUM ANALYZE' I get the results from query2.txt > > As you can see, the indexes are not used any longer. > Why? > > Bye/2 > --- > Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting > Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] > http://www.plaut.de | http://www.Reifenberger.com > Bye/2 --- Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] index not used afer VACUUM ANALYZE
Hi,
I hav a db as specified in nit.sql
flows has 763488 entries.
After dropping/creating/loading the db and running auswert.sh I get
the attached result from query1.txt.
After 'VACUUM ANALYZE' I get the results from query2.txt
As you can see, the indexes are not used any longer.
Why?
Bye/2
---
Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting
Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED]
http://www.plaut.de | http://www.Reifenberger.com
CREATE TABLE flows (
date date,
sip inet,
dip inet,
"type" integer,
sport_low integer[],
dport_low integer[],
sport_high integer[],
dport_high integer[],
sdpkgs integer,
dspkgs integer,
sdbytes integer,
dsbytes integer,
"first" timestamp without time zone,
"last" timestamp without time zone
);
CREATE TABLE protos (
pnum integer,
pname text
);
CREATE TABLE networks (
nnet cidr,
nname text
);
CREATE TABLE volumen (
"year" integer,
week integer,
snet inet,
dnet inet
);
CREATE UNIQUE INDEX flows_0 ON flows USING btree (date, sip, dip, "type");
CREATE UNIQUE INDEX networks_0 ON networks USING btree (nnet);
CREATE INDEX flows_1 ON flows USING btree ("type");
CREATE UNIQUE INDEX protos_0 ON protos USING btree (pnum);
CREATE INDEX flows_2 ON flows USING btree (date);
vdat='2003-07-01'
bdat='2003-08-01'
# Auswertung tabelleninhalt
echo "#"
echo "# Anzahl Sätze in der DB, von Datum, bis Datum, Anzahl Tage"
echo "#"
psql -U pgsql nitpicker << EOF1
explain select count(*),
min(date) as Von, max(date) as Bis, max(date)-min(date) as Tage
from flows;
EOF1
# Auswertung Tage, Protokoll, Bytes, Pakete aufsummiert
echo "#"
echo "# Tagesstatistik je Protokoll"
echo "#"
psql -U pgsql nitpicker << EOF2
explain select f.date as datum, p.pname as Protokoll,
sum(f.sdbytes) + sum(f.dsbytes) as Bytes,
sum(f.sdpkgs) + sum(f.dspkgs) as Pakete
from protos p, flows f
where
f.date >= '$vdat' and f.date <= '$bdat' and
f.type = p.pnum
group by datum, protokoll
order by datum, Bytes desc
;
EOF2
echo "#"
echo "# Tagesstatistik gesamt"
echo "#"
psql -U pgsql nitpicker << EOF3
explain select f.date as datum,
sum(f.sdbytes) + sum(f.dsbytes) as Bytes,
sum(f.sdpkgs) + sum(f.dspkgs) as Pakete
from flows f
where
f.date >= '$vdat' and f.date <= '$bdat'
group by datum
order by datum, Bytes desc
;
EOF3
echo "#"
echo "# Top 50: max( Bytes )"
echo "#"
psql -U pgsql nitpicker << EOF4
explain select count(*),
network(set_masklen(sip,16)), network(set_masklen(dip,16)),
sum(sdbytes) + sum(dsbytes) as bytes
from flows f
where
f.date >= '$vdat' and f.date <= '$bdat'
group by network(set_masklen(sip,16)), network(set_masklen(dip,16))
order by bytes desc
limit 50;
EOF4
#psql -U pgsql nitpicker << EOF
# select
# -- n1.nname as src, n2.nname as dst
# count(*)
# from flows f, networks n1, networks n2, protos p
# where
# f.sip << n1.nnet and
# f.dip << n2.nnet
#EOF
#psql -U pgsql nitpicker -c "\
#select \
# f.sip, f.dip, p.pname, \
# f.sdpkgs, f.dspkgs \
# from flows f, protos p where \
# not f.sip << '194.39.177.0/24' and \
# not f.sip << '194.99.75.0/24' and \
# not f.sip = '195.212.179.2' and \
# not f.dip << '194.39.177.0/24' and \
# not f.dip << '194.99.75.0/24' and \
# not f.dip = '195.212.179.2' and \
# f.type = p.pnum \
# order by sip, dip;"
#psql -U pgsql nitpicker << EOFX
# drop table volumen;
# create table volumen (
#year int4,
#week int4,
#snet inet,
#dnet inet
# );
# drop table n_temp;
# create table n_temp (
#year int4,
#week int4,
#snet inet,
#dnet inet,
#sdbytes int8,
#dsbytes int8,
#sdpkgs int8,
#dspkgs int8
# );
#EOFX
#date
#psql -U pgsql nitpicker << EOF
# insert into n_temp
# select
#date_part( 'year', f.date ) ,
#date_part( 'week', f.date ),
#n.nnet, network( set_masklen( f.dip, 16 ) ),
#sum( f.sdbytes ), sum( f.dsbytes ),
#sum( f.sdpkgs ), sum( f.dspkgs )
# from flows f, networks n
# where
#f.sip <<= n.nnet and
#not f.dip <<= n.nnet
# group by f.date, n.nnet, network( set_masklen( f.dip, 16 ) )
# union
# select
#date_part( 'year', f.date ) ,
#date_part( 'week', f.date ),
#n.nnet, network( set_masklen( f.sip, 16 ) ),
#sum( f.dsbytes ), sum( f.sdbytes ),
#sum( f.dspkgs ), sum( f.sdpkgs )
# from flows f, networks n
# where
#f.dip <<= n.nnet and
#not f.sip <<= n.nnet
# group by f.date, n.nnet, network( set_masklen( f.sip, 16 ) )
# union
# select
#date_part( 'year', f.date ) ,
#date_part( 'week', f.date ),
#network( set_masklen( f.sip, 16 ) ), network( set_masklen( f.dip, 16 ) ),
#sum( f.sdbytes ), sum( f.dsbytes ),
#sum( f.sdpkgs ), sum( f.dspkgs )
# from flows f, networks n
# where
#not f.sip <<= n.nnet and
#not f.dip <<= n.nnet
# group by f.date, network( set_masklen( f.sip, 16 ) ), network( set_masklen( f.dip,
16 ) )
#EOF
#date
#
[BUGS] FAQ: 1.13) How do I submit a bug report?
Hi, I just installed 7.4beta1 and hit a small bug, so I thought it would be fine to submit a bug report. I found a document doc/FAQ, which tells me to look at http://www.PostgreSQL.org/bugs/bugs.php. But this page does not exist. Ok - the problem I found is in psql. The help-page with LANG=de_DE (psql --help) lists -l twice and misses option --help. I just checked a 7.3.3-installation. Same problem there. Tommi Mäkitalo ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Tom Lane wrote: Kevin Houle <[EMAIL PROTECTED]> writes: The nature of the bug is that an 'lo_read' operation performed with DBD::Pg caused a segfault with postgresql-libs-7.3.2 and "hangs" on files >= 32768 bytes with postgresql-libs-7.3.4. The hang is actually a read() loop on the socket generating EAGAIN error on each read(). I finally realized what's going on here. 7.3 branch CVS tip should fix it. Good news. I'll test as soon as I'm able and report back only if I still see an issue. No news is good news. Thanks for the effort, Tom. Kevin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] contrib-global.mk and sql.in question
On Fri, 22 Aug 2003 22:31:26 -0600 Robert Creager <[EMAIL PROTECTED]> said something like: > > I'm using GNU sed version 4.0.3. > Sorry, missed the rest: GNU make 3.80 Mandrake Linux 9.1 PG 7.4Beta1 -- 22:44:51 up 21 days, 15:26, 4 users, load average: 2.00, 2.03, 2.03 pgp0.pgp Description: PGP signature
Re: [BUGS] repalloc bug
The odds that this is a bug in repalloc, and not in your own code, are
nil.
regards, tom lane
Dear Tom Lane,
Thanks for quick response. Trying to focus what kind of bug could infest my
code, I reduced the code to a small example that illustrates the infaust
effect. I've tried to follow as much as possible the manual, so I'm trying
to figure what's wrong.
This is the source code:
---> snip <---
#include
#include
#include
#include
#include
#include
#include
#include
typedef struct
{
TupleDesc tupdesc;
u_int32_t size;
u_int8_t *buf;
} repalloc_test_t;
void repalloc_bubble(u_int8_t *buf, u_int32_t s)
{
buf = repalloc(buf, s);
bzero(buf, s);
}
PG_FUNCTION_INFO_V1(repalloc_test);
Datum repalloc_test(PG_FUNCTION_ARGS)
{
FuncCallContext *funcctx;
repalloc_test_t *d;
u_int32_t i;
MemoryContext oldcontext;
funcctx = SRF_FIRSTCALL_INIT();
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
d = funcctx->user_fctx = (repalloc_test_t *)
palloc(sizeof(repalloc_test_t));
bzero(d, sizeof(repalloc_test_t));
d->tupdesc = RelationNameGetTupleDesc("repalloc_type");
d->size = 32;
d->buf = palloc(d->size);
bzero(d->buf, d->size);
for(i = 0; i < d->size; i++)
elog(WARNING, "TEST A: d->buf[%d] = %d", i, d->buf[i]);
d->size = 64;
repalloc_bubble(d->buf, d->size);
for(i = 0; i < d->size; i++)
elog(WARNING, "TEST B: d->buf[%d] = %d", i, d->buf[i]);
funcctx->slot = TupleDescGetSlot(d->tupdesc);
MemoryContextSwitchTo(oldcontext);
funcctx = SRF_PERCALL_SETUP();
SRF_RETURN_DONE(funcctx);
}
> snip <-
I've then created the following script to load the library and execute it:
---> snip <---
CREATE TYPE "repalloc_type" AS
(
"count" integer,
"size" integer
);
CREATE OR REPLACE FUNCTION repalloc_test() RETURNS setof repalloc_type AS
'path/to/lib.so' LANGUAGE C IMMUTABLE WITH (isStrict);
SELECT * FROM repalloc_test();
DROP FUNCTION repalloc_test();
DROP TYPE repalloc_type;
---> snip <---
This is the output of the WARNING messages:
---> snip <---
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[0] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[1] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[2] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[3] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[4] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[5] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[6] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[7] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[8] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[9] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[10] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[11] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[12] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[13] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[14] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[15] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[16] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[17] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[18] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[19] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[20] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[21] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[22] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[23] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[24] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[25] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[26] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[27] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[28] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[29] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[30] = 0
psql:repalloc_test.sql:7: WARNING: TEST A: d->buf[31] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[0] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[1] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[2] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[3] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[4] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[5] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[6] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[7] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[8] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[9] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[10] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[11] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[12] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->buf[13] = 0
psql:repalloc_test.sql:7: WARNING: TEST B: d->b
[BUGS] contrib-global.mk and sql.in question
Hey, Just wondering if the rule: %.sql: %.sql.in sed 's,MODULE_PATHNAME,$$libdir/$*g' $< >$@ is supposed to produce files like this: CREATE OR REPLACE FUNCTION pgxml_parse(text) RETURNS boolean AS '$libdir/pgxml_dom' LANGUAGE c STRICT; I'm using GNU sed version 4.0.3. I find the following patch makes it work for me, but I'm not sure if this is a bug, feature, or something else? *** contrib-global.mk.orig 2003-08-22 22:20:33.0 -0600 --- contrib-global.mk 2003-08-22 22:22:26.0 -0600 *** *** 225,231 ifneq (,$(MODULES)$(MODULE_big)) %.sql: %.sql.in ! sed 's,MODULE_PATHNAME,$$libdir/$*,g' $< >$@ endif ifdef PROGRAM --- 225,231 ifneq (,$(MODULES)$(MODULE_big)) %.sql: %.sql.in ! @sed 's:MODULE_PATHNAME:$(libdir)/$*:g' $< >$@ endif ifdef PROGRAM -- 22:17:58 up 21 days, 14:59, 4 users, load average: 2.10, 2.04, 2.01 pgp0.pgp Description: PGP signature
[BUGS] setof type and later table bug??
Hi! Guys please help me, it this example I create function sergi() thats return a rows, and everything is OK, function works well, but if I execute a SQL query : ALTER TABLE DUPA DROP COLUMN nazwa; or everything using ALTER TABLE, my function crashes and error is sth. like query type and function type do not match ! What's it??? How to solve it withought reloading table. Is it a bug PZDR; Sergiusz. CREATE TABLE dupa (id int NOT NULL, nazwa varchar(44) NOT NULL, primary key(id) ); INSERT INTO dupa VALUES(1, 'a'); INSERT INTO dupa VALUES(2, 'b'); INSERT INTO dupa VALUES(3, 'c'); INSERT INTO dupa VALUES(4, 'd'); INSERT INTO dupa VALUES(5, 'e'); INSERT INTO dupa VALUES(6, 'f'); INSERT INTO dupa VALUES(7, 'g'); INSERT INTO dupa VALUES(8, 'h'); CREATE OR REPLACE FUNCTION sergi() RETURNS SETOF DUPA AS ' DECLARE rec RECORD; BEGIN FOR rec IN SELECT * FROM DUPA LOOP RETURN NEXT rec; /* Each RETURN NEXT command returns a row */ END LOOP; RETURN; END; ' LANGUAGE 'plpgsql'; ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] FAQ: 1.13) How do I submit a bug report?
Tommi Maekitalo writes: > Ok - the problem I found is in psql. The help-page with LANG=de_DE (psql > --help) lists -l twice and misses option --help. I just checked a > 7.3.3-installation. Same problem there. I fixed this in the 7.3 and 7.4 branches. Thanks. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
