[BUGS] BUG #2783: insufficient base table information for updating or refreshing
The following bug has been logged online: Bug reference: 2783 Logged by: mike Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.5 Operating system: windows 2000 Description:insufficient base table information for updating or refreshing Details: if using 8.01.0200 driver, can select table, but cannot insert picture if using 8.02.0200 driver, can insert picture, but cannot select table is it safe to use 8.2 beta 3 for production use? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] No error when FROM is missing in subquery
Also check that the mov_id column exists in the table/view that you are running the SELECT DISTINCT against. Pgsql does not throw an error (at least prior to 8.2) if the column referenced by the select statement for the IN clause does not exist. It will run only SELECT * FROM movies.names in this case. Mike On Tue, 2006-12-19 at 06:01 +0100, Thomas H. wrote: > >> >> SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id > >> >> WHERE > >> >> mov_name like '%, %' LIMIT 2) > >> > >> IF the subquery would only have returned 2 ids, then there would be at > >> most > >> like +/-10 records affected. each mov_id can hold one or more (usuals up > >> to > >> 5) names. but here, the subquery seemed to return ~3700 distinct mov_ids, > >> thus around 37000 names where damaged by the following programmatical > >> updates instead of only a hands full... > >> > > > > have you tested the query in psql? > > what results do you get? > > the data is damaged so the result isn't the same... regenearting it now from > a backup. > > from first tests i would say it returned records with names that match the > WHERE in the subselect. i guess what happened is: it took each record in > movies.names, then run the subquery for that record which resulted in "WHERE > mov_id IN (mov_id)" = true for records with a ', ' in the name and "WHERE > mov_id IN ()" = false for all others. > > - thomas > > > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] No error when FROM is missing in subquery
You are right as usual My apologies yet again. I have wrongly assumed that the lower statement would run first since it is enclosed in parenthesis. On Tue, 2006-12-19 at 00:48 -0500, Tom Lane wrote: > mike <[EMAIL PROTECTED]> writes: > > Pgsql does not throw an error (at least prior to 8.2) if the column > > referenced by the select statement for the IN clause does not exist. > > My, there's a lot of misinformation in this thread. > > The reason there's no error thrown is that the reference to mov_id in > the sub-SELECT is a perfectly legal outer reference to the mov_id column > available from the upper SELECT. If the column truly did not exist > anywhere in the tables used in the query, it would have thrown an error. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2855: SEGV on PL/PGSQL function
The following bug has been logged online: Bug reference: 2855 Logged by: Mike Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: RHEL AS 4.3 x86_64 Description:SEGV on PL/PGSQL function Details: (retyping this by hand ... forgive any mistakes) I am getting a SEGV every time I attempt to run the following plpgsql function: CREATE FUNCTION drop_empty_ip_partitions(VARCHAR) RETURNS SETOF VARCHAR AS $$ DECLARE table_basename ALIAS FOR $1; is_empty INTEGER; BEGIN FOR first_octet IN 0..255 LOOP BEGIN EXECUTE 'SELECT 1 FROM ' || quote_ident(table_basename || '_ip' || first_octet) || ' LIMIT 1' INTO is_empty; IF is_empty IS NULL THEN EXECUTE 'DROP TABLE ' || quote_ident(table_basename || '_ip' || first_octet); RETURN NEXT quote_ident(table_basename || '_ip' || first_octet); END IF; EXCEPTION WHEN undefined_table THEN RAISE NOTICE 'Table for octet % does not exist', first_octet; END; END LOOP; RETURN; END; $$ LANGUAGE plpgsql; Basically, I have tables partitioned by the first octet of an ip, i.e. table_ip1, table_ip2, table_ip3, etc. The function simply goes through the all the possible ip partition tables for a given prefix and drops any that are empty. I have another very similar plpgsql function that simply returns the number of elements in each partition, and that causes a SEGV as well. I am on RHEL AS 4.3 x86_64 on an 8-way HP Opteron box using the 8.2 PGDG RPMS. I recently upgraded from 8.1 and reloaded (pg_dumpall; cat | psql) my databases successfully. As I periodically do, I dropped all the tables in one of the databases and was in the process of reloading them when I ran into this issue. I can successfully run the plpgsql command on another (similar) database. I configured the system to drop a core, and get the following backtrace: pfree () AtEOSuXact_SPI () DefineSavepoint () RollbackAndReleaseCurrentSubTransaction () plpgsql_compile () from /usr/lib64/pgsql/plpgsql.so Let me know what other information I can provide. I'm hoping that its not a trivial thing that I missed in the release notes ... ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #3746: installation fails
The following bug has been logged online: Bug reference: 3746 Logged by: Mike Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Win2003/WinXP Description:installation fails Details: I tried to install PostgreSQL two times on different systems. You will not be able to promote your software if the install fails. Conclusion: The installation process is too complicated! I talked with a colleague about it and he says he experienced the same problems. You will not be able to expand your user base if you do not eliminate these problems!!! Error: The program "postgres" is needed by initdb but was not found in the same directory as "C:/Program Files/PostgreSQL/8.2/bin/initdb". Check your installation. >>> I just clicked "OK" for every option. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
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
#
Re: [BUGS] index not used afer VACUUM ANALYZE
On Mon, 25 Aug 2003, Stephan Szabo wrote:
> Date: Mon, 25 Aug 2003 00:43:56 -0700 (PDT)
> From: Stephan Szabo <[EMAIL PROTECTED]>
> To: mike <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [BUGS] index not used afer VACUUM ANALYZE
>
> On Thu, 21 Aug 2003, mike wrote:
>
> > 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?
>
> It looks like the row estimates changed to say that a large % of the rows
> match the condition. Is that true? In any case, what does EXPLAIN
Partially.
I have statistical records (763488) - various IP-Traffic - collected for one
month.
After collection I try to condense the data for dayly statistics.
The EXPLAIN ANALYZE output is attached:
a1.txt is before, a2.txt after VACUUM ANALYZE run.
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
#
# Anzahl Sätze in der DB, von Datum, bis Datum, Anzahl Tage
#
QUERY PLAN
Aggregate (cost=41037.49..41037.50 rows=1 width=4) (actual time=6307.81..6307.82
rows=1 loops=1)
-> Seq Scan on flows (cost=0.00..31493.88 rows=763488 width=4) (actual
time=0.02..3134.26 rows=763488 loops=1)
Total runtime: 6323.81 msec
(3 rows)
#
# Tagesstatistik je Protokoll
#
QUERY PLAN
-
Sort (cost=14991.34..14991.66 rows=131 width=52) (actual time=16473.23..16473.77
rows=159 loops=1)
Sort Key: f.date, (sum(f.sdbytes) + sum(f.dsbytes))
-> HashAggregate (cost=14984.76..14986.73 rows=131 width=52) (actual
time=16471.51..16472.41 rows=159 loops=1)
-> Hash Join (cost=2.62..14947.53 rows=2482 width=52) (actual
time=1.53..11924.14 rows=753800 loops=1)
Hash Cond: ("outer"."type" = "inner".pnum)
-> Index Scan using flows_2 on flows f (cost=0.00..14786.46 rows=3818
width=24) (actual time=0.15..4180.55 rows=753800 loops=1)
Index Cond: ((date >= '2003-07-01'::date) AND (date <=
'2003-08-01'::date))
-> Hash (cost=2.30..2.30 rows=130 width=36) (actual time=1.17..1.17
rows=0 loops=1)
-> Seq Scan on protos p (cost=0.00..2.30 rows=130 width=36)
(actual time=0.06..0.62 rows=130 loops=1)
Total runtime: 16499.55 msec
(10 rows)
#
# Tagesstatistik gesamt
#
QUERY PLAN
---
Sort (cost=14834.22..14834.23 rows=2 width=20) (actual time=8519.01..8519.12 rows=31
loops=1)
Sort Key: date, (sum(sdbytes) + sum(dsbytes))
-> GroupAggregate (cost=0.00..14834.21 rows=2 width=20) (actual
time=309.70..8518.71 rows=31 loops=1)
-> Index Scan using flows_2 on flows f (cost=0.00..14786.46 rows=3818
width=20) (actual time=0.19..3989.96 rows=753800 loops=1)
Index Cond: ((date >= '2003-07-01'::date) AND (date <=
'2003-08-01'::date))
Total runtime: 8519.59 msec
(6 rows)
#
# Top 50: max( Bytes )
#
QUERY PLAN
-
Limit (cost=14884.07..14884.20 rows=50 width=72) (actual time=15852.17..15852.70
rows=50 loops=1)
-> Sort (cost=14884.07..14884.58 rows=201 width=72) (actual
time=15852.16..15852.34 rows=50 loops=1)
Sort Key: (sum(sdbytes) + sum(dsbytes))
-> HashAggregate (cost=14872.36..14876.38 rows=201 width=72) (actual
time=15406.83..15551.54 rows=23410 loops=1)
-> Index Scan using flows_2 on flows f (cost=0.00..14824.64 rows=3818
width=72) (actual time=0.21
Re: [BUGS] index not used afer VACUUM ANALYZE
On Mon, 25 Aug 2003, Stephan Szabo wrote: > Date: Mon, 25 Aug 2003 08:52:34 -0700 (PDT) > From: Stephan Szabo <[EMAIL PROTECTED]> > To: mike <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [BUGS] index not used afer VACUUM ANALYZE > > On Mon, 25 Aug 2003, mike wrote: > > > On Mon, 25 Aug 2003, Stephan Szabo wrote: > > > > > Date: Mon, 25 Aug 2003 00:43:56 -0700 (PDT) > > > From: Stephan Szabo <[EMAIL PROTECTED]> > > > To: mike <[EMAIL PROTECTED]> > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: [BUGS] index not used afer VACUUM ANALYZE > > > > > > On Thu, 21 Aug 2003, mike wrote: > > > > > > > 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? > > > > > > It looks like the row estimates changed to say that a large % of the rows > > > match the condition. Is that true? In any case, what does EXPLAIN > > > > Partially. > > I have statistical records (763488) - various IP-Traffic - collected for one > > month. > > After collection I try to condense the data for dayly statistics. > > > > The EXPLAIN ANALYZE output is attached: > > a1.txt is before, a2.txt after VACUUM ANALYZE run. > > There are two things that jump out at me, the first is that the group > aggregate estimates on the after are way higher than reality and that it > looks to me that the sort before the group aggregate is taking longer than > expected. What do you have sort_mem set to since that will affect whether > sorts are in memory and I believe whether it thinks it can use a hash > aggregate on that nubmer of rows. > sort_men was at the default. But setting it to 10240 doesn't seem to change the seqscan on flows. 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 8: explain analyze is your friend
Re: [BUGS] index not used afer VACUUM ANALYZE
Hi,
On Tue, 26 Aug 2003, Stephan Szabo wrote:
...
> But does it change the amount of time the query actually takes to run?
> seqscans are not always slower nor are they necessarily the actual problem
> here. The problem seems to be choosing a group aggregate + sort which is
> taking alot of time, if you look at the real time on the steps below that
> it's approximately the same for seqscan or index scan.
Ok, with plenty of sort_mem (327680) the seqscan seems to be faster.
Using 64000 shared_buffers it's not that amazing since nothing hits the disks.
As last times aus1.txt is before aus2.txt after the VACUUM ANALYZE.
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
#
# Anzahl Sätze in der DB, von Datum, bis Datum, Anzahl Tage
#
QUERY PLAN
Aggregate (cost=28924.49..28924.49 rows=1 width=4) (actual time=3408.51..3408.51
rows=1 loops=1)
-> Seq Scan on flows (cost=0.00..19380.88 rows=763488 width=4) (actual
time=0.02..1671.79 rows=763488 loops=1)
Total runtime: 3409.05 msec
(3 Zeilen)
#
# Tagesstatistik je Protokoll
#
QUERY PLAN
-
Sort (cost=14419.56..14419.89 rows=131 width=52) (actual time=13472.11..13472.38
rows=159 loops=1)
Sort Key: f.date, (sum(f.sdbytes) + sum(f.dsbytes))
-> HashAggregate (cost=14412.99..14414.95 rows=131 width=52) (actual
time=13470.92..13471.59 rows=159 loops=1)
-> Hash Join (cost=2.62..14375.76 rows=2482 width=52) (actual
time=10.58..7998.45 rows=753800 loops=1)
Hash Cond: ("outer"."type" = "inner".pnum)
-> Index Scan using flows_2 on flows f (cost=0.00..14214.68 rows=3818
width=24) (actual time=0.18..2987.40 rows=753800 loops=1)
Index Cond: ((date >= '2003-07-01'::date) AND (date <=
'2003-08-01'::date))
-> Hash (cost=2.30..2.30 rows=130 width=36) (actual time=6.23..6.23
rows=0 loops=1)
-> Seq Scan on protos p (cost=0.00..2.30 rows=130 width=36)
(actual time=0.09..0.43 rows=130 loops=1)
Total runtime: 13478.65 msec
(10 Zeilen)
#
# Tagesstatistik gesamt
#
QUERY PLAN
---
Sort (cost=14262.45..14262.45 rows=2 width=20) (actual time=5141.80..5141.86 rows=31
loops=1)
Sort Key: date, (sum(sdbytes) + sum(dsbytes))
-> GroupAggregate (cost=0.00..14262.44 rows=2 width=20) (actual
time=193.42..5141.57 rows=31 loops=1)
-> Index Scan using flows_2 on flows f (cost=0.00..14214.68 rows=3818
width=20) (actual time=0.12..2423.80 rows=753800 loops=1)
Index Cond: ((date >= '2003-07-01'::date) AND (date <=
'2003-08-01'::date))
Total runtime: 5142.25 msec
(6 Zeilen)
#
# Top 50: max( Bytes )
#
QUERY PLAN
-
Limit (cost=14312.30..14312.42 rows=50 width=72) (actual time=8398.72..8398.97
rows=50 loops=1)
-> Sort (cost=14312.30..14312.80 rows=201 width=72) (actual time=8398.70..8398.79
rows=50 loops=1)
Sort Key: (sum(sdbytes) + sum(dsbytes))
-> HashAggregate (cost=14300.59..14304.61 rows=201 width=72) (actual
time=8188.61..8296.36 rows=23410 loops=1)
-> Index Scan using flows_2 on flows f (cost=0.00..14252.86 rows=3818
width=72) (actual time=0.15..4768.39 rows=753800 loops=1)
Index Cond: ((date >= '2003-07-01'::date) AND (date <=
'2003-08-01'::date))
Total runtime: 8432.66 msec
(7 Zeilen)
#
# Anzahl Sätze in der DB, von Datum, bis Datum, Anzahl Tage
#
QUERY PLAN
Aggregate (cost=28924.49..28924.49 rows=1 width=4) (actual time=3408.29..3408.29
rows=1 loops=1)
-> Seq Scan on flows (cost=0.00..19380.88 rows=763488 width=4) (actual
time=0.02..1671.06 rows=7634
[BUGS] Backups with pg_dumpall do not restore all data
POSTGRESQL BUG REPORT TEMPLATE Your name : Mike Martin Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : AMD duron Operating System (example: Linux 2.4.18) : Linux 2.6.3 PostgreSQL version (example: PostgreSQL-7.4.2): PostgreSQL-7.4.2 Compiler used (example: gcc 2.95.2) : n/a Please enter a FULL description of your problem: There appears to be a problem with pg_dumpall. I maintaain a DB of around 6-7 tables, being a finance and contacts system. If I use pg_dumpall, two of the tables are restored without any data. These are linked together. Even more curious the data is dumped into the dump file. If I use pg_dump there is no problem. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] Backups with pg_dumpall do not restore all data
POSTGRESQL BUG REPORT TEMPLATE Your name : Mike Martin Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : AMD duron Operating System (example: Linux 2.4.18) : Linux 2.6.3 PostgreSQL version (example: PostgreSQL-7.4.2): PostgreSQL-7.4.2 Compiler used (example: gcc 2.95.2) : n/a Please enter a FULL description of your problem: There appears to be a problem with pg_dumpall. I maintaain a DB of around 6-7 tables, being a finance and contacts system. If I use pg_dumpall, two of the tables are restored without any data. These are linked together. Even more curious the data is dumped into the dump file. If I use pg_dump there is no problem. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Log entry asking to contact support
Hi, I was running a manual vacuum through pgadmin 1.4.1 on a database and my connection to the database was lost during it. I reconnected to the database, went to Tools->Server Status->Log File and there is an entry that says: "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information". I am running XP Pro SP2. Database is 8.1.1 and is not located on the same machine. I also have autovacuum enabled. I then tried to re-vacuum the database by using the local copy of pgadmin on the database machine. When it got to the same table and began working it stopped again. This time an error message was displayed instead of the connection being closed. The error: "failed to re-find parent key in "idx_volume_consultant" Should I just recreate the index and try to vacuum (full) again? I want to assume it got corrupted during the original vacuum attempt. I have been starting the vacuum from the database name level in pgadmin. I would be happy to try and give more info if I can. I initially posted this to pgadmin-support but was asked to post here. Mike ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2145: FTP Mirror to download is not found
Have you already tried to close your browser, re-open the browser and gone to the site again? I have had problems in the past where I went to a download site, made a selection, canceled the download before it finished, re-navigated through the site, returned to the download site and then none of them worked. The steps I took are listed in the pgsql-www mailing list someplace. Mike On Wed, 2006-01-04 at 16:10 +, Glenn Gentry wrote: > The following bug has been logged online: > > Bug reference: 2145 > Logged by: Glenn Gentry > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.1 > Operating system: Win32 > Description:FTP Mirror to download is not found > Details: > > I tried every suggested USA mirror for FTP download of Win32 product and > none of them worked. > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #7846: Documentation: Should FOUND be documented as an output of UPDATE statement?
The following bug has been logged on the website: Bug reference: 7846 Logged by: Mike Sherrill Email address: m...@fontling.com PostgreSQL version: 9.1.6 Operating system: Ubuntu Linux 12.04 Description: Documentation for the SQL UPDATE statement doesn't mention that it sets the FOUND variable. (Refer to sql-update.html, "Outputs".) That behavior *is* documented, but only in plpgsql-statements.html (Basic Statements, section 39.5.5). I understand the difference between a SQL statement and a PL/PGSQL statement. But if I were looking for the effects and side-effects of an UPDATE statement, I'd go to the docs for UPDATE, not for PL/PGSQL basic statements. I think that's what most people would do, especially if they didn't have prior knowledge of the FOUND variable. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4406: silent install error
The following bug has been logged online: Bug reference: 4406 Logged by: Mike Gagnon Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Windows XP Description:silent install error Details: Hi, When I try to do a silent install, I have created the user and password in windows before trying this: MSIEXEC /i "postgresql-8.3-int.msi" /qb /log "c:\logfile.txt" ADDLOCAL="server,nls,psql,pgadmin,includefiles,libfiles,binfiles" INTERNALLAUNCH=1 DOSERVICE=1 CREATESERVICEUSER=0 DOINITDB=1 SERVICEDOMAIN="" SERVICEACCOUNT="postgres" SERVICEPASSWORD="randompass1" SERVICENAME="PostgreSQL Database Server 8.3" SUPERUSER="postgres" SUPERPASSWORD="postgrespw" LOCALE=C ENCODING=SQL_ASCII LISTENPORT=5432 PERMITREMOTE=1 PL_PGSQL=1 PL_PERL=1 PL_PERLU=1 PL_TCL=0 PL_TCLU=0 PL_PYTHONU=0 BASEDIR="c:\mydir\PostgreSQL\8.3" I then get the following error: "User account ¡¡¡s\¡W does not exist" It's as if the installer doesn't pick up the correct username I'm giving it... Is there any way around this? Many thanks, Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4411: One click install broken
The following bug has been logged online: Bug reference: 4411 Logged by: Mike Tegtmeyer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: MacOS10.5 Description:One click install broken Details: During one click install on clean MacOS 10.5.4 system I get the numerous following from installer " Unable to unpack file to /Library/PostgreSQL/8/3/scripts/runpsql.sh/rsrc" also "Problem running post-install step. Installation may not complete correctly The database cluster initialisation failed." -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5093: Prepared query gives different PGresult than exec'd equivalent
The following bug has been logged online:
Bug reference: 5093
Logged by: Mike Pomraning
Email address: m...@pilcrow.madison.wi.us
PostgreSQL version: 8.4.1
Operating system: Linux i686 2.6.18-128.7.1.el5
Description:Prepared query gives different PGresult than exec'd
equivalent
Details:
The following short program installs a RULE to SELECT two rows INSTEAD of
INSERTing into a VIEW.
When it PQexec's the insertion, I get a PGresult object with PQntuples == 2.
However, when it PREPAREs/EXECUTEs the very same SQL, the PGresult has
PQntuples == 0.
My expectation is that the prepared statement would return the same PGresult
as its unprepared equivalent.
Am I using the API incorrectly, is my expectation amiss, is this a bug,
etc.?
/*
$ ./a.out 'dbname=postgres password="mypass"'
PGresult of exec() ('INSERT 0 0'): ntuples 2
PGresult of execPrepd() ('INSERT 0 0'): ntuples 0
*/
#include
#include
static char sql[] = "INSERT INTO v VALUES (1)";
int
main(int argc, char **argv) {
PGconn *pg;
PGresult *r;
pg = PQconnectdb(argv[1] ? argv[1] : "");
if (!pg || PQstatus(pg) == CONNECTION_BAD) {
printf("connection failed\n");
return 1;
}
PQexec(pg, "CREATE TEMPORARY VIEW v AS SELECT 1 WHERE 1=0");
PQexec(pg, "CREATE RULE r AS ON INSERT TO v DO INSTEAD (SELECT 1 UNION
SELECT 2)");
r = PQexec(pg, sql);
printf("PGresult of exec() ('%s'): ntuples %d\n", PQcmdStatus(r),
PQntuples(r));
PQprepare(pg, "pstmt", sql, 0, NULL);
r = PQexecPrepared(pg, "pstmt", 0, NULL, NULL, NULL, 0);
printf("PGresult of execPrepd() ('%s'): ntuples %d\n", PQcmdStatus(r),
PQntuples(r));
PQexec(pg, "DROP RULE r");
return 0;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5160: complex query parsing bug
The following bug has been logged online: Bug reference: 5160 Logged by: Mike Landis Email address: mlan...@pnmx.com PostgreSQL version: 1.8.4 Operating system: Vista Description:complex query parsing bug Details: The SQL parser in pgAdmin III v1.8.4 build 7358 thinks that there should be more input at the end of the following multi-join query. Subqueries have been verified correct. I think the parser got lost... Mike SELECT SP.basis, SP.shares, SP.stock_id, SP.portfolio_id, HP.last_date, HP.price, symbol, exchange, company_name FROM stocks JOIN (SELECT HP_LAST.stock_id, last_date, price FROM (SELECT stock_id, date, close AS price FROM historical_stock_prices ) AS HP_ALL JOIN (SELECT stock_id, MAX(date) AS last_date FROM historical_stock_prices GROUP BY stock_id ) AS HP_LAST ON HP_ALL.stock_id = HP_LAST.stock_id AND HP_ALL.DATE = HP_LAST.last_date ) AS HP JOIN (SELECT stock_id, portfolio_id, SUM(num_units) AS shares, SUM(cost_basis) AS basis FROM stock_positions WHERE sale_date IS NULL AND portfolio_id = 1 GROUP BY stock_id, portfolio_id ) AS SP ON SP.stock_id = HP.stock_id -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] getting libpqd.lib and libpqd.dll for postgesql 8.4.1 on Vista with VS8 or cygwin g++
I am trying to experiment with the libpqxx API and postgresql 8.4.1 on a 32-bit Vista machine. Libpqxx wants release and debug libraries for libpq available. libpq.dll ships with the binary release of PG and libpq.lib ships with the source tree, but debug versions have to be built from source. Would it be a huge violation of release sensibilities to bundle debug libs with the binary or source trees? Regardless of what the team decides long term, in the short term I need to build win32 debug libraries for libpq (libpqd.dll, libpqd.lib) and I've been unable to build them from source. At the command line using nmake, I get errors indicating that pg_config_os.h and winsock2.h are being included multiple times... suggesting that my include path is fouled up. Using cygwin make/g++, pg_config_os.h and winsock2.h are being included multiple times... also the include path. When I try converting win32.mak into a VS8 project, it complains that it can't convert the project. When I create a VS8 project from scratch, setting the include path to "D:\Programs\cygwin\usr\src\postgresql-8.4.1\src\include";"C:\Program Files\Microsoft\VS8\VC\include";D:\Programs\cygwin\usr\include VS8 produces many errors indicating that winsock2.h, unistd.h, ws2tcpip.h (possibly other header files) are being included multiple times. What include path(s) should I be using with these compilers (cygwin make/g++ or nmake/cl from VS8? Thanks, Mike Landis
[BUGS] BUG #5268: PQgetvalue incorrectly returns 0
The following bug has been logged online: Bug reference: 5268 Logged by: Mike Landis Email address: mlan...@pnmx.com PostgreSQL version: 8.4.1 Operating system: Vista Description:PQgetvalue incorrectly returns 0 Details: When I execute the following SQL: "SELECT COUNT(*) FROM information_schema.tables WHERE table_name='proxies'" in the PGAdmmin 1.10.0, rev 7945-7946 query tool, I get "1" (the correct answer). When I run the exact same SQL in a C program, I get a result set with one tuple and one field (so far so good), but when I run PQgetvalue(resultSet,0,0) I get "0" (wrong answer). Am I missing something? You can't do squat in a client program without PQgetvalue(). Is any sort of regression test being run against libpq functions? What can I do to get this resolved? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] email addresses
Can you please stop displaying the email addresses on bug reports? It's one thing to require an email address - it's another thing entirely to publish it for spam address harvesting bots. This is an example page... http://archives.postgresql.org/pgsql-bugs/2009-12/msg00092.php
Re: [BUGS] BUG #5268: PQgetvalue incorrectly returns 0
Try the following, where
mystring is an extension of std::string...
mystring sql( "SELECT COUNT(*) FROM information_schema.tables
WHERE table_name='proxies' ");
int
GetIntFromSQL(
mystring& sql )
{
// if there's more than one
record in the ResultSet, still only returns the first float
int
retVal = -1;
PGresult* res =
GetQueryResult( sql );
if
( res )
{
int
nTuples = PQntuples(res);
int
nFields = PQnfields(res);
if
( nTuples > 0 &&
nFields > 0 )
{
char
* val =
PQgetvalue(res,0,0);
// get first column, first
field
retVal = atoi(
val );
}
PQclear( res
);
}
return
retVal;
}
PGresult*
GetQueryResult(
mystring& sql )
{
// run a query that may
return a result set
PGresult*
res = PQexec( conn,
sql.c_str() );
if
( res )
{
int
status = PQresultStatus(res);
if
( status != PGRES_TUPLES_OK )
{
// what happened?
fprintf( stderr,
"GetQueryResult(%s) ->
%s\n", sql.c_str(),
PQerrorMessage(conn) );
PQclear( res
);
// possibly moot
res = NULL;
}
}
else
{
fprintf( stderr,
"GetQueryResult: insufficient memory to run:
%s\n", sql.c_str() );
throw
"GetQueryResult: insufficient
memory";
}
return
res;
}
At 02:14 AM 1/7/2010, you wrote:
-BEGIN PGP SIGNED
MESSAGE-
Hash: SHA1
On Thu, Jan 07, 2010 at 04:11:03AM +, Mike Landis wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5268
> Logged by:
Mike Landis
> Email address: mlan...@pnmx.com
> PostgreSQL version: 8.4.1
> Operating system: Vista
> Description: PQgetvalue
incorrectly returns 0
> Details:
>
> When I execute the following SQL:
>
> "SELECT COUNT(*) FROM information_schema.tables WHERE
table_name='proxies'"
>
> in the PGAdmmin 1.10.0, rev 7945-7946 query tool, I get
"1" (the correct
> answer). When I run the exact same SQL in a C program, I get a
result set
> with one tuple and one field (so far so good), but when I run
> PQgetvalue(resultSet,0,0) I get "0" (wrong answer).
>
> Am I missing something? You can't do squat in a client program
without
> PQgetvalue(). Is any sort of regression test being run against
libpq
> functions?
Hm. I don't know for sure, but I'd assume that PGAdmin relies on
libpq...
> What can I do to get this resolved?
Could you show us a more complete test case? That might help in
pin-pointing the problem.
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFLRYnoBcgs9XrR2kYRAjV/AJ9+HAZZu5sFKuHw1vp7aZNLKM7ykwCfQ+FX
q+NXaFojGP7uS4O/4Km/stM=
=zblK
-END PGP SIGNATURE-
No virus found in this incoming message.
Checked by AVG -
www.avg.com
Version: 9.0.725 / Virus Database: 270.14.127/2603 - Release Date:
01/06/10 02:35:00
Re: [BUGS] BUG #5268: PQgetvalue incorrectly returns 0
Pick a database and table that exists, configure
the string cconstants, compile and run the attached cpp, get 0 instead of
1 (that you get in pgAdmin...
Where's can I download the libpq source? Maybe I can find and/or
fix the problem myself.
#include
#include // on Vista
#include// from: the postgres 8.4 install include directory,
for me... D:\Programs\PostgreSQL\8.4\include
// configure these constants and get a '0' even though the same query produces
a '1' in pgAdmin
const char* pgUser = "us"; // PG user
const char* pgDbms = "db"; // database
const char* pgPass = "xyz"; // password
const char* pgHost = "localhost"; // host domain or IP
const char* pgTable = "tableName"; // a table that exists in the pgDbms
// on UNIX you can obviously revert the main() declaration to main( int argc,
char** argv )
int _tmain( int argc, _TCHAR* argv[] )
{ charconnInfo[128];
sprintf( connInfo, "host=%s dbname=%s user=%s password=%s", pgHost,
pgDbms, pgUser, pgPass );
PGconn* conn = PQconnectdb( connInfo );
if ( PQstatus(conn) == CONNECTION_OK )
{ // in my case... SELECT COUNT(*) FROM
information_schema.tables WHERE table_name='proxies'
sprintf( connInfo, "SELECT COUNT(*) FROM
information_schema.tables WHERE table_name='%s'",
pgTable );
PGresult* res = PQexec( conn, connInfo );
if ( res )
{ if ( PQresultStatus(res) == PGRES_TUPLES_OK )
{ int nTuples = PQntuples(res);
int nFields = PQnfields(res);
if ( nTuples > 0 && nFields > 0 )
{ char* val = PQgetvalue(res,0,0);
// get first column, first field
fprintf( stderr, "val=%s\n", val );
}
}
PQclear( res );
// possibly moot
res = NULL;
}
PQfinish( conn );
}
return 0;
}
//
// you'll need to link with.libpq, in my case, that's:
D:\Programs\PostgreSQL\8.4\lib\libpq.lib
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Comparison of Strings
I am running PostgreSQL 7.0.2 on sparc-sun-solaris2.8, compiled by gcc 2.95.2 I have a database table whose contents are cs302=# select * from author; isbn | author --+- '1565921941' | 'Meyer, Jon' '1565921941' | 'Downing, Troy' '0201100886' | 'Aho, Alfred V.' '0201100886' | 'Sethi, Ravi' '0201100886' | 'Ullman, Jeffrey D.' '0878518096' | 'Maloney, Elbert S.' '0870211641' | 'Maloney, Elbert S.' '0441865003' | 'Thomson, Amy' '031296' | 'Vinge, Vernor' '0030860784' | 'Hungerford, Thomas W.' '0201038099' | 'Knuth, Donald E.' '1565920015' | 'Gilly, Daniel' (12 rows) If I run the following command, I get [the string matches the first two entries in the table]: cs302=# select * from author where isbn = '1565921941'; isbn | author --+ (0 rows) If I change the = to a ~, I get cs302=# select * from author where isbn ~ '1565921941'; isbn | author --+- '1565921941' | 'Meyer, Jon' '1565921941' | 'Downing, Troy' (2 rows) Is there something about comparison of strings with the = that I don't see, that makes it different from string matching with the ~? --- Michael Schulte Specialist in Computer Science UM-St. Louis [EMAIL PROTECTED] 8001 Natural Bridge Road (314) 516 5239 St. Louis, MO 63121 USA http://cs.umsl.edu/~schulte
[BUGS] Referencial integerity problem
Briefly, I create two tables, one having a column which references the
other and which implements cascade deletes and updates. I create a user
who has modify access on one table, but only select on the referenced
table. This user is not allowed to insert a record into the referencing
table - the error message refers to the referenced table.
I don't think referential integrity should work this way. Any thoughts?
Details:
create table foo (
foo char(10)
);
revoke all on foo from public on foo;
create table bar (
foo char(10) references foo (foo) on delete cascade on update cascade,
parm int
);
revoke all on bar from public on bar;
create user lim ;
grant select on foo to lim;
grant insert on bar to lim;
grant update on bar to lim;
grant delete on bar to lim;
grant select on bar to lim;
bash$ psql -U lim test
Password:
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test=> select * from foo ;
foo
foo
bar
(2 rows)
test=> insert into bar values ('foo', 1);
ERROR: foo: Permission denied.
test=>
--
Mike Howard <[EMAIL PROTECTED]>
Re: [PHP] [BUGS] PostgreSQL / PHP Overrun Error
Well it really isn't your code (true), but the only thing that is changed is the 7.0-7.1- Was a data length changed on the return or something that could affect this? -- Mike - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Mike Rogers" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 26, 2001 1:23 PM Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > "Mike Rogers" <[EMAIL PROTECTED]> writes: > > This problem is of great concern to me and I have been working for days > > trying to debug it myself and find other reports, with little success. The > > line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by > > what this claims) which is the following function [the > > efree(PGG(last_notice)) line]. > > This isn't our code, so you'd likely have better luck complaining on > some PHP-related list. But it looks to me like this code is simply > trying to free any previous notice message before it stores the new > one into PGG(last_notice) (whatever the heck that is). I'm guessing > that that pointer is uninitialized or has been clobbered somehow. > > regards, tom lane > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PHP] [BUGS] PostgreSQL / PHP Overrun Error
Sorry: PHP 4.0.6 (with memory leak patch [download listed right below php-4.0.6.tar.gz download- It was a problem]) PostgreSQL 7.1.3 Apache 1.3.20 (with mod_ssl- but it does the same thing without mod_ssl) -- Mike - Original Message - From: "mlw" <[EMAIL PROTECTED]> To: "Mike Rogers" <[EMAIL PROTECTED]> Cc: "Tom Lane" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 26, 2001 1:55 PM Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > Mike Rogers wrote: > > > Well it really isn't your code (true), but the only thing that is changed is > > the 7.0-7.1- Was a data length changed on the return or something that > > could affect this? > > What version of PHP are you using? > > > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PHP] [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error
There is a problem in PHP-4.0.6. Please use PHP4.0.7 or 4.0.8 and the problem will be solved. This can be obtained from CVS -- Mike - Original Message - From: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> To: "Mike Rogers" <[EMAIL PROTECTED]>; "mlw" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 26, 2001 10:31 PM Subject: RE: [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error > Have you recompiled PHP to link against the new postgres libraries? > > Chris > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Rogers > > Sent: Thursday, 27 September 2001 1:07 AM > > To: mlw > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: Re: [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error > > > > > > Sorry: > > PHP 4.0.6 (with memory leak patch [download listed right below > > php-4.0.6.tar.gz download- It was a problem]) > > PostgreSQL 7.1.3 > > Apache 1.3.20 (with mod_ssl- but it does the same thing > > without mod_ssl) > > -- > > Mike > > > > - Original Message - > > From: "mlw" <[EMAIL PROTECTED]> > > To: "Mike Rogers" <[EMAIL PROTECTED]> > > Cc: "Tom Lane" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Wednesday, September 26, 2001 1:55 PM > > Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > > > > > > > Mike Rogers wrote: > > > > > > > Well it really isn't your code (true), but the only thing that is > > changed is > > > > the 7.0-7.1- Was a data length changed on the return or > > something that > > > > could affect this? > > > > > > What version of PHP are you using? > > > > > > > > > > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > > > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [HACKERS] [PG MAIL LISTS] SEND OUT ALL????
if you look at the originating time for all of the messages that got sent out of when it was sent from the host machine (with HELO host). Clearly it was done on an admin side. -- Mike - Original Message - From: "Marc G. Fournier" <[EMAIL PROTECTED]> To: "Mike Rogers" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, November 16, 2001 3:26 PM Subject: Re: [BUGS] [HACKERS] [PG MAIL LISTS] SEND OUT ALL > > someone, either intentially or accidentally, sent out a load to the lists > ... > > > On Fri, 16 Nov 2001, Mike Rogers wrote: > > > Why did it just send out tons of mail since September of this year- every > > message? > > -- > > Mike > > > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] [PG MAIL LISTS] SEND OUT ALL????
Why did it just send out tons of mail since September of this year- every message? -- Mike ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] pg_restore --data-only ignored
While upgrading to 7.1.3 (from 7.1.2) I discovered that pg_restore was not
honouring the --data-only command line option. Can't actually remember if
it worked in 7.1.2 or not.
Particulars:
postgresql-7.1.3.tar.gz
compiled under Linux mandrake 7.2
command used from a shell script
pg_restore --dbname=${dbName}2 --data-only -v --superuser=postgres $dbDump
I could get around this by using a list file and then editing it to only
include data lines, but thought it should be reported as a bug.
--
=
Mike Finn
Tactical Executive Systems
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] PostgreSQL / PHP Overrun Error
I have just upgraded to the new PostgreSQL 7.1.3 (from 7.0.3) and have been
experiencing a pretty serious problem:
On one particular page, in what seems to be completely random instances,
I get buffer overruns and either 0-rows or a crashed apache child. Turning
on PHP's --enable-debug, I receive the following:
[Wed Sep 26 06:21:12 2001] Script: '/path/to/script.php'
---
pgsql.c(167) : Block 0x086A6DF8 status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
End: Unknown
---
Sometimes it will actually crash mid-way (probably overwrote some valuable
code):
---
pgsql.c(167) : Block 0x08684290 status:
Beginning: Overrun (magic=0x111A, expected=0x7312F8DC)
[Wed Sep 26 09:22:46 2001] [notice] child pid 8710 exit signal Segmentation
fault (11)
This problem is of great concern to me and I have been working for days
trying to debug it myself and find other reports, with little success. The
line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by
what this claims) which is the following function [the
efree(PGG(last_notice)) line].
static void
_notice_handler(void *arg, const char *message)
{
PGLS_FETCH();
if (! PGG(ignore_notices)) {
php_log_err((char *) message);
if (PGG(last_notice) != NULL) {
efree(PGG(last_notice));
}
PGG(last_notice) = estrdup(message);
}
}
Can anyone provide further input as to why this is causing problems? The
PHP code works sometimes and not others, and it seems to be only that one
script, so I do not believe it to be a hardware issue.
Any thoughts? I can provide any further system information if needed. I
have tried recompiling pgsql, php and apache with different optimizations
[including none at all and debug mode on as i have now] with little change
in the result.
Thanks in advance;
--
Mike
cc: pgsql-hackers; pgsql-php; pgsql_bugs
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] case sensititvity bug in foreign keys on cygwin
Configuration:
Windows 2000 Server
cygwin 2.78.2.9
PostgreSQL 7.1.3
psqlODBC 7.1.8
pgAdmin II 1.1.66
Bug:
Capital letters cannot be used in column names used in foreign key
constraints
All Smalls succeeds:
-- Table: significance
CREATE TABLE "significance" (
"significanceid" int4 NOT NULL,
"desc" varchar(255),
CONSTRAINT "pk_significance" PRIMARY KEY ("significanceid"));
-- Table: primaryword
CREATE TABLE "primaryword" (
"exerciseid" int4 NOT NULL,
"significanceid" int4 NOT NULL,
CONSTRAINT "pk_primaryword" PRIMARY KEY ("exerciseid"),
CONSTRAINT "fk_primaryword_significance" FOREIGN KEY
(significanceid) REFERENCES "significance" (significanceid) );
With just the foreign table name capitalized, it also succeeds:
-- Table: Significance
CREATE TABLE "Significance" (
"significanceid" int4 NOT NULL,
"desc" varchar(255),
CONSTRAINT "pk_significance" PRIMARY KEY ("significanceid"));
-- Table: primaryword
CREATE TABLE "primaryword" (
"exerciseid" int4 NOT NULL,
"significanceid" int4 NOT NULL,
CONSTRAINT "pk_primaryword" PRIMARY KEY ("exerciseid"),
CONSTRAINT "fk_primaryword_significance" FOREIGN KEY
(significanceid) REFERENCES "Significance" (significanceid) );
Capitalizing just the foreign column name fails with what seems to be an
incorrect error:
-- Table: significance
CREATE TABLE "significance" (
"Significanceid" int4 NOT NULL,
"desc" varchar(255),
CONSTRAINT "pk_significance" PRIMARY KEY ("Significanceid"));
-- Table: primaryword
CREATE TABLE "primaryword" (
"exerciseid" int4 NOT NULL,
"significanceid" int4 NOT NULL,
CONSTRAINT "pk_primaryword" PRIMARY KEY ("exerciseid"),
CONSTRAINT "fk_primaryword_significance" FOREIGN KEY
(significanceid) REFERENCES "significance" (Significanceid) );
Fails with error
Description: Error while executing the query;
Error: UNIQUE constraint matching given keys for refernced table
"significance" not found
Capitalizing just the child column name fails :
-- Table: Significance
CREATE TABLE "significance" (
"significanceid" int4 NOT NULL,
"desc" varchar(255),
CONSTRAINT "pk_significance" PRIMARY KEY ("significanceid"));
-- Table: primaryword
CREATE TABLE "primaryword" (
"exerciseid" int4 NOT NULL,
"Significanceid" int4 NOT NULL,
CONSTRAINT "pk_primaryword" PRIMARY KEY ("exerciseid"),
CONSTRAINT "fk_primaryword_significance" FOREIGN KEY
(Significanceid) REFERENCES "significance" (significanceid) );
With the following error:
Description: Error while executing the query;
Error: Columns referenced in foreign key constraint not found
I could not get foreign keys to succeed if there were any caps in the column
names, although caps in primary key constraints seems to work just fine.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] case-sensitivity inconsistency in quoted column aliases in FROM subselects
POSTGRESQL BUG REPORT TEMPLATE Your name : Mike Hoolehan Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.0.26 ELF) : RH 7.2, Kernel 2.4.9-13 PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 Compiler used (example: gcc 2.95.2) : gcc 2.96 (rpm version) Please enter a FULL description of your problem: if a quoted column alias in a FROM clause sub-select contains upper-case chars, then that column cannot be later referenced without using quotes Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- SELECT * FROM (SELECT col1 as "Foo" from table1) AS innerQuery WHERE Foo = 'whatever'; results in "ERROR: Attribute 'foo' not found" no matter what capitalization is used for "Foo" in the where clause (i.e. foo='whatever', FOO='whatever', etc). I assume this is a bug, since if the column is aliases as "foo" (with quotes, all lowercase), then the column can later be referenced without quotes with case-insensitivity. If you know how this problem might be fixed, list the solution below: - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build commands
Your name : Mike Riendeau
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Sun Sparc 20
Operating System (example: Linux 2.0.26 ELF) : Solaris 2.5.1
PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3
Compiler used (example: gcc 2.95.2) : gcc 2.95.2
Please enter a FULL description of your problem:
I am having a problem with v7.1.3 PostgreSQL commands generating
Seg. Faults on exit.
* I have built v7.0.2 from the sources, on Sun Solaris 2.5.1
and have been running this version with success.
I run postgres as follows:
postmaster -B 16 -N 8 -p8000 -i
I need the -B and -N options to allow IpcMemshare to work.
* I am running the server in my own account, not a root installation,
* not under a postgres account.
Version 7.1.3 build and exec issues:
--
- Built with the exact same config options as v7.0.2
** Configure process ***
./configure --prefix=/home/mriendea --with-tcl
--with-tclconfig=/home/mriendea/lib --with-tkconfig=/home/mriendea/lib
--with-includes=/home/mriendea/include --with-pgport=8000 --with-odbc
Configure did not report any fatal errors.
CONFIG.LOG ##
.
.
configure: In function `main':
configure:6562: `rl_completion_append_character' undeclared (first use in
this function)
configure:6562: (Each undeclared identifier is reported only once
configure:6562: for each function it appears in.)
configure: failed program was:
#line 6553 "configure"
#include "confdefs.h"
#include
#ifdef HAVE_READLINE_READLINE_H
# include
#elif defined(HAVE_READLINE_H)
# include
#endif
int main() {
rl_completion_append_character = 'x';
; return 0; }
configure:6584: checking for rl_completion_matches
configure:6639: checking for finite
configure:6648: gcc -o conftest -g -I/home/mriendea/include conftest.c
-lz -lresolv -lge
n -lnsl -lsocket -ldl -lm -lreadline -ltermcap 1>&5
.
.
.
### CONFIG.LOG #
* build process ***
'gmake' reports:
GMAKE #
Various warnings also reported in v7.0.2 build.
...All of PostgreSQL successfully made. Ready to install.
*** results *
- postmaster seems to run OK with the same options as v7.0.2
I am starting it with the pg_ctl command with the
-o "-B16 -N8 -i" arg and env PGHOST, PGPORT and PGDATA.
- initdb functions with no problem. It created the database files.
- createdb manages to create a database, but Seg Faults on exit.
- psql is able to access the database created with createdb,
but Seg Faults on exit.
- regression tests don't get past postmaster for the latter
reasons.
** GNU debugger ( configged w/ --enable-debug)
bash-2.02{temp}$ gdb ./psql
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (sparc-sun-solaris2.5.1), Copyright 1996 Free Software Foundation,
Inc...
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) run foo
Starting program: /home/mriendea/temp/./psql foo
warning: Unable to find dynamic linker breakpoint function.
warning: GDB will be unable to debug shared library initializers
warning: and track explicitly loaded dynamic code.
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
foo=#
foo=#
foo=#
foo=#
foo=#
foo=# \h
Available help:
ABORT CREATE TRIGGERGRANT
ALTER GROUP CREATE TYPE INSERT
ALTER USERCREATE VIEW LOAD
BEGIN DECLARE LOCK
CHECKPOINTDELETEMOVE
CLOSE DROP AGGREGATENOTIFY
CLUSTER DROP DATABASE REINDEX
COMMENT DROP FUNCTION RESET
COMMITDROP GROUPREVOKE
COPY DR
Re: [BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com
Your name : Mike Riendeau Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Sun Sparc 20 Operating System (example: Linux 2.0.26 ELF) : Solaris 2.5.1 PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 Compiler used (example: gcc 2.95.2) : gcc 2.95.2 Please enter a FULL description of your problem: I am having a problem with v7.1.3 PostgreSQL commands generating Seg. Faults on exit. (Continued) Steps taken on this pass: 1) built readline4.2a successfully. 2) Ran PGv7.1.3 configure as follows with a clean cache. ./configure --prefix=/home/mriendea --with-tcl --with-tclconfig=/home/mriendea/lib --with-tkconfig=/home/mriendea/lib --with-includes=/home/mriendea/include --with-pgport=8000 --with-odbc --enable-debug --with-libs=/home/mriendea/lib --enable-debug Without 'gmake install' of the new readline lib, the script sees the same readline used to build PGv7.0.2 and completes successfully. Of course the Seg Fault behavior is apparent. 3) 'gmake install' of the new readline lib. 4) Ran PGv7.1.3 configure with a clean cache again. The script now sees the new readline4.2a lib and crashes with the identical problem reported by Holger Mittewald bug #490. (test following optreset bails the config script for some reason.) rpath is the same (at least in all Makes in the source root) Both config runs have the same parameters. So, something other than the setting of rpath is going on here. Or I do not understand how it all works (Definite possibility). Synopsys of configure with above switches: PROCESS Tested readlineConfig gmake installedrun version libs - Pgv7.0.2systemyes yes v7.0.2 yes Pgv7.1.3systemyes yes v7.0.2 v7.1.3 pgsql, createdb seem to work with new db. (brief testing) Pgv7.1.3systemyes yes v7.1.3 Seg. Faults on exit for pgsql, createdb ... Pgv7.1.3v4.2a bails n/a n/an/a after optreset Giving up soon, Mike Riendeau ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com
Follow up: PGv7.2 still suffers from the Seg. Fault on exit problem reported below on that system. However, Ran the new v7.2 on a new machine with the following config: Architecture (example: Intel Pentium): Sun sparc, Ultra-2 Operating System (example: Linux 2.0.26 ELF) : Solaris 2.8 PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.2 Compiler used (example: gcc 2.95.2) : gcc 2.95.2 On, the new machine, the problem goes away. After some investigation, it appears to be some problem with our run-time linker cleaning up on the older systems. Regards, M Riendeau -Original Message- From: Riendeau, Mike [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 4:04 PM To: Tom Lane; Riendeau, Mike Cc: [EMAIL PROTECTED] Subject: RE: [BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com mands Your name : Mike Riendeau Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Sun Sparc 20 Operating System (example: Linux 2.0.26 ELF) : Solaris 2.5.1 PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 Compiler used (example: gcc 2.95.2) : gcc 2.95.2 Please enter a FULL description of your problem: I am having a problem with v7.1.3 PostgreSQL commands generating Seg. Faults on exit. (Continued) Steps taken on this pass: 1) built readline4.2a successfully. 2) Ran PGv7.1.3 configure as follows with a clean cache. ./configure --prefix=/home/mriendea --with-tcl --with-tclconfig=/home/mriendea/lib --with-tkconfig=/home/mriendea/lib --with-includes=/home/mriendea/include --with-pgport=8000 --with-odbc --enable-debug --with-libs=/home/mriendea/lib --enable-debug Without 'gmake install' of the new readline lib, the script sees the same readline used to build PGv7.0.2 and completes successfully. Of course the Seg Fault behavior is apparent. 3) 'gmake install' of the new readline lib. 4) Ran PGv7.1.3 configure with a clean cache again. The script now sees the new readline4.2a lib and crashes with the identical problem reported by Holger Mittewald bug #490. (test following optreset bails the config script for some reason.) rpath is the same (at least in all Makes in the source root) Both config runs have the same parameters. So, something other than the setting of rpath is going on here. Or I do not understand how it all works (Definite possibility). Synopsys of configure with above switches: PROCESS Tested readlineConfig gmake installedrun version libs - Pgv7.0.2systemyes yes v7.0.2 yes Pgv7.1.3systemyes yes v7.0.2 v7.1.3 pgsql, createdb seem to work with new db. (brief testing) Pgv7.1.3systemyes yes v7.1.3 Seg. Faults on exit for pgsql, createdb ... Pgv7.1.3v4.2a bails n/a n/an/a after optreset Giving up soon, Mike Riendeau ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] PG_DUMP Load
I seem to be having a problem with the pg_dump command on the Linux 2.2.x operating system. I have found that in doing a 425MB dump via TCP/IP over a network, I receive up to 90.00 load on the dual P2 and dual P3 servers from a start of 0.25 or so. This is a gradule increase in load peaking up there, but still this is completely unacceptable from a systems perspective. Why is the load going so high? Why is this putting such stress on the system? Why doesn't this happen on load backups (which only peak up around 1.3 or so). The server appears unresponsive during these times and processes time out and fail. Has anyone else has similar problems with pg_dump 7.1.3? -- Mike ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] gmake does not work for Postgresql-8.1.4
Gmake does not work for the postgresql-8.1.4 source code on Windows XP. I created MinGW with the MinGW 5.0.3.exe (both current & applicant) and MySyS 1.0.10. Gmake was not available so I used the included mysys make – GNU version 79. After succeeding with “./configure –without-zlib” it then failed on “make” as follows: rt/win32" -c -o fseeko.o fseeko.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -I../../src/port -DFRONTEND -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -c -o getrusage.o getrusage.c In file included from ../../src/include/rusagestub.h:17, from getrusage.c:18: c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/sys/time.h:27: error: redefinition of `struct timezone' c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/sys/time.h:40: error: conflicting types for 'gettimeofday' ../../src/include/port.h:266: error: previous declaration of 'gettimeofday' was here c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/sys/time.h:40: error: conflicting types for 'gettimeofday' ../../src/include/port.h:266: error: previous declaration of 'gettimeofday' was here make[2]: *** [getrusage.o] Error 1 make[2]: Leaving directory `/c/postgresql-8.1.4/src/port' make[1]: *** [install] Error 2 make[1]: Leaving directory `/c/postgresql-8.1.4/src' make: *** [install] Error 2. I tracked down zlib but never did figure out where to place it. I retried using the guide in libpqxx which said: extract, compile & install zlib by ./configure –prefix=c:/mingw/local && make && make && make install – this failed. I then tried ./configure –prefix=c:/mingw/local –with-includes=c:/mingw/local/include –with-libs=c:/mingw/local/lib make && make install but it had an issue with make. Mike Bassett e-mail [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2815: Editing / Creating ODBC on Windows fails libintl-2.dll not found
The following bug has been logged online: Bug reference: 2815 Logged by: mike godshall Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows 2003 webserver edition Description:Editing / Creating ODBC on Windows fails libintl-2.dll not found Details: I uninstalled 8.1.5 today and installed 8.2. I also had psqlodbc_08_01_0200 installed but did not manually uninstall that. After upgrading to 8.2 I visited a web page that used ODBC to pull some data on to it. The 2 queries worked (were based on views). I then continued on to another page where a query went directly against a table. I received an error that column ctid did not exist. I never had a column named that in the table being queried. I then went to start->control panel->admin tools->odbc connections. My previous odbc connections I had set up from 08_01_0200 were still there. Upon selecting one I received the error message "The application failed to initialize because libintl-2.dll was not found." I completely uninstalled postgres 8.2, uninstalled psqlodbc, and deleted the odbc connections from previous postgres installations. Reinstalled 8.2 including the odbc options. I received the same errors above upon trying to create a new odbc connection. I have uninstalled the odbc included with 8.2 and reinstalled psqlodbc_08_01_0200 by downloading the odbc msi. I can now create and edit postgres odbc connections. My apps no longer are giving me the columns not found either. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3752: query yields "could not find block containing chunk", then server crashes
Just forwarding this info along as Zdenek requested... Turns out this problem is not a bug in pg8.3, it was a problem with our custom data type. I have since dropped the custom data type and am now using standard pg float4 arrays. Did the dump and restore, and our app works just fine, no crash when the query is run. BTW- PG8.3 seriously rocks! We've got some large tables that had very poor performance in PG8.1... things are really snappy now, HOT usage really helps our app (as shown by the handy pg_stat_all_tables). Mike Zdenek Kotala wrote: > Mike Charnoky wrote: >> It seems this problem has to do with a custom data type we are using. I >> am working on eliminating this custom data type, as it is becoming too >> much of a pain to support (it is basically float4[]). If the problem >> persists after the data type conversion, I will follow up. Otherwise, I >> think this was an error in our custom type code (maybe corruption during >> dump/reload) > > Thanks for update. > >> Would the stack trace still be useful? Where would I find the dump >> file? I didn't see anything... > > If you are sure, that it is in your data type implementation then > probably not. You can find core file usually in postgres data directory > if you have core file generation enabled by ulimit command. You can get > stack trace by gdb. > > Zdenek > >> >> Mike >> >> Zdenek Kotala wrote: >>> Michael Charnoky wrote: >>> >>> >>>> 2007-11-15 15:38:03.880 PST: ERROR: could not find block containing >>>> chunk >>>> 0x902fb98 >>> This message appears in AllocSetFree or AllocSetRealloc function in >>> aset.c source. In both function it means that defined context does not >>> contain memory block. By my opinion there should be two more probable >>> scenarios: >>> >>> 1) memory block does not exist -> for AllocSetFree it means e.g. double >>> free or for AllocSetRealloc it means that somebody want to realloc >>> memory which was already freed. >>> >>> 2) memory is still allocated but in different context. However, palloc >>> and pfree should control it. >>> >>> >>> By my opinion it is double free problem, but without stack trace or >>> reproduction scenario it is difficult to find it. >>> >>> Zdenek > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3790: pg_restore error canceling statement due to user request
The following bug has been logged online: Bug reference: 3790 Logged by: Mike C. Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3beta3 Operating system: Linux 2.6.16.21-0.8-xen #1 SMP Mon Jul 3 18:25:39 UTC 2006 i686 i686 i386 GNU/Linux Description:pg_restore error canceling statement due to user request Details: I don't know if this is either a wording change, or a more serious bug, but when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta3 created database (createdb command only), I repeatedly see: ERROR: canceling statement due to user request CONTEXT: automatic analyze of table "dbs.public.entity_event" ERROR: canceling statement due to user request CONTEXT: automatic analyze of table "dbs.public.status_event" ERROR: canceling statement due to user request CONTEXT: automatic analyze of table "dbs.public.entity_event" ERROR: canceling statement due to user request CONTEXT: automatic analyze of table "dbs.public.entity_event" ... For all tables I believe. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Vers. 8.3.0: "make check" fails dismally
Hello postgresql developers, assuming, of course, somebody actually reads this bug report. Naively checking the build using "make check" (yes, gnu make, and as an unprivaleged user) fails all tests. The apparent reason is that postgres cannot find its shared libraries. FIX: Enter $ export LD_LIBRARY_PATH=/usr/src/postgresql-8.3.0/src/test/regress/tmp_check/install/usr/local/lib before "make check" and all the tests are then successful. Cheers, Mike Dowling -- Dr. Michael L. Dowling Gaußstr. 27 38106 Braunschweig Germany ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #3983: pgxs files missing from binary installation
The following bug has been logged online: Bug reference: 3983 Logged by: Mike Leahy Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: Win32 Description:pgxs files missing from binary installation Details: I've tried to compile the PL/R module, which I have been doing with 8.2.x versions. PL/R requires the pgxs.mk file, and determines its location from pg_config. The location of pgxs.mk reported by pg_config in my case (from windows binary installer) is "C:/Program Files/PostgreSQL/8.3/lib/pgxs/src/makefiles/pgxs.mk". However, there is no such pgxs folder located in the /lib directory...nor is there any other instance of pgxs.mk anywhere in the PostgreSQL install location. There also seem to be no pgxs files in any of the other distributed 8.3 binaries for win32. Tom Lane's suggestion in the pgsql-general mailing list is that this is a bug with the installer. At this time, I'm unable to compile PL/R for PostgreSQL, which I think has a growing user base that relies on the installer normally posted at http://www.joeconway.com/plr. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3983: pgxs files still missing in win32 install (8.3.1)
Is this actually a bug, or is there a specific reason that the pgxs files omitted in the windows installer? I noticed the 8.3.1 installer has been posted (as the updates had appeared on my linux machines). From what I can tell, the 8.3.1 version of the win32 installer is still missing pgxs.mk and any related files. Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4166: Alter table add column from PgAdminIII
The following bug has been logged online: Bug reference: 4166 Logged by: Mike Gagnon Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1-1 Operating system: Windows XP Description:Alter table add column from PgAdminIII Details: Hi Postgres Experts, I used PGAdmin III to add a character varying column(400) length, not null default ''. I get the column displayed in psql when I do a simple query like SELECT * from MyTable limit 1; When I try to do Update MyTable set NewColumn='something'; I get the error saying that the column doesn't exist It thinks it exists when I do my select, but it doesn't recognize this new column in my UPDATE... I'm scared... I have a deadline coming up and I'm praying this one gets fixed soon. Many thanks! Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Large PG_DUMPs going into memory?
I am dumping a rather large PostgreSQL database with 895,000 rows or so. running 'pg_dump -d databse -u --table=tbl -f ./tbl.sql' makes a 425MB file. The problem is that whether the database is remote or local [i have tried running it on the DB server itself with the same result], it takes up a good half gigabyte of RAM for the course of the dump. Why does it load all of this into memory on the client machine rather than output it as it comes in. On one server, this has caused the machine to swap out a good 250MB to disk, running up the system load to very high numbers. The database server seems to serve it as any other request, but the client server that is running pg_dump seems to be struggling. My main question is not that it does it but why this is how it is done? Isn't it more efficient to dump it out to the file or STDOUT (if -f isn't specified) rather than load the entire result set into memory? It's not sorting it or anything. Any help would be appreciated. -- Mike ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[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] ON DELETE triggers don't work as documented
If PostgreSQL failed to compile on your computer or you found a bug that is likely to be specific to one platform then please fill out this form and e-mail it to [EMAIL PROTECTED] To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] If you not only found the problem but solved it and generated a patch then e-mail it to [EMAIL PROTECTED] instead. Please use the command "diff -c" to generate the patch. You may also enter a bug report at http://www.postgresql.org/ instead of e-mail-ing this form. POSTGRESQL BUG REPORT TEMPLATE Your name : Mike Glover Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Mixed ix86 Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.x PostgreSQL version (example: PostgreSQL-7.2.1): PostgreSQL-7.2.1 Compiler used (example: gcc 2.95.2) : gcc 2.96 Please enter a FULL description of your problem: The docs state (section 23.9): If a non-NULL value is returned then the operation proceeds with that row value. Note that returning a row value different from the original value of NEW alters the row that will be inserted or updated. the above suggests that returning NEW for a delete should cause the delete to proceed. In fact, I've found it necessary to return a record with the row format of the table and all empty fields. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- db=# create table test (field1 int, field2 text); CREATE db=# create or replace function test_trigger () returns opaque as ' mdisys'# DECLARE mdisys'# BEGIN mdisys'# return NEW; mdisys'# END mdisys'# ' language plpgsql; CREATE db=# create trigger run_test_trigger before delete on test for each row execute procedure test_trigger(); CREATE db=# insert into test values (1, 'foo'); INSERT 123700 1 db=# insert into test values (2, 'bar'); INSERT 123701 1 db=# delete from test where field1=1; DELETE 0 db=# select * from test; field1 | field2 + 1 | foo 2 | bar (2 rows) db=# If you know how this problem might be fixed, list the solution below: - I believe this is a documentation bug. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #856: coredump
On Thu, Dec 26, 2002 at 12:01:02PM -0500, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > postgresql=# CREATE USER mpech777; > > CREATE USER > > postgresql=# alter USER mpech777 password ''; > > server closed the connection unexpectedly > > Hm, it works fine here. You'll need to give more details about Cool. I knew it. > platform, configuration options, any nondefault settings in > postgresql.conf, etc. A stack trace from the core dump would be > helpful as well, in case we still can't reproduce it. It was OpenBSD 3.2-CURRENT with propolice. With patches for gcc from 25/12/2002 i can't reproduce coredump anymore. So, it was OpenBSD related bug. --mpech ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] pg_tables view definition incorrect??
version --- PostgreSQL 7.3.2 on i586-pc-linux-gnu, compiled by GCC 2.95.3 (1 row) View "pg_catalog.pg_tables" Column| Type | Modifiers -+-+--- schemaname | name| tablename | name| tableowner | name| hasindexes | boolean | hasrules| boolean | hastriggers | boolean | View definition: SELECT n.nspname AS schemaname, c.relname AS tablename, pg_get_userbyid(c.relowner) AS tableowner, c.relhasindex AS hasindexes, c.relhasrules AS hasrules, (c.reltriggers > 0) AS hastriggers FROM (pg_class c LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") OR (c.relkind = 's'::"char")); Given that 'S' => Sequence and 's' => special shouldn't the last condition in the WHERE clause be: c.relkind = 'S'::"char" instead of c.relkind = 's'::"char" ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] SysV startup script name in binary RPM distribution
I'm not a subscriber to the list. Please copy any responses directly to me.
Thanks.
It's such a minor, but annoying bug, and is easily fixed:
The stock startup script included in the RPM (I currently use the 7.3.3 RPM
for RH7.3), /etc/rc.d/init.d/postgresql, sets the service name (the $NAME
variable within the script) to the basename by which it was called, with
this line:
NAME=`basename $0`
This seems like a logical thing to do, but it causes a problem because the
system calls the script by its various softlinks (such as
"/etc/rc.d/rc3.d/S85postgresql" or "/etc/rc.d/rc1.d/K15postgresql").
The best example of the effect is that during a normal boot into run level
3, the service name gets set to "S85postgresql" instead of the obviously
correct "postgresql." This is reflected both on the console ("Starting
S85postgresql...[Ok]"), and in the /var/lock/subsys/S85postgresql lock file,
for example. Later when doing a "service postgresql restart" or something
similar, the script is supposed to delete that lock file but fails to,
because it *now* thinks its name is just "postgresql." That ridiculous
/var/lock/subsys/S85postgresql file just hangs around perpetually (like a
thorn in my side).
A trivial fix would be either to change the assignment to
NAME=`basename $0 | /bin/sed -e 's/^[SK][0-9][0-9]//'`
and add the sed requirement to the postgresql-server package, or use two
lines, such as
NAME=`basename $0`
NAME=${NAME#[SK][0-9][0-9]}
which I know works with bash, but I'm not sure if it will work with an
old-style Bourne shell. Incidentally, is there any strong reason it doesn't
just standardize and become the following?
NAME=postgresql
Thanks. Please save me the 10 seconds it takes to reimplement this fix every
time I upgrade. :)
Mike Nerone
/* The only secure computer is one that is unplugged from the network -- and
the wall. */
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] buglet in 7.1.4
Lamar Owen wrote: On Tuesday 09 March 2004 10:46 am, Tom Lane wrote: Neil Conway <[EMAIL PROTECTED]> writes: BTW, I can't really see the harm in putting out 7.1.x and 7.2.x releases to fix compilation issues on modern systems. Also, quite frankly, I don't want to encourage people to keep using such old releases. If they are installing on a new machine they should update to something newer and less buggy. We need the older versions to be compilable on newer systems to ease in version upgrades and migration. How could they find themselves in a situation where they have a 7.1 installation that requires dumping for migration, but no binaries due to compilation errors? Isn't that a rather low-probability scenario? Mike Mascari ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] make check regression "test stats" failed
I found my problem. My iptables setup was not allowing UDP communication from source 127.0.0.1 and some high port to destination 127.0.0.1 and the same high port. Once I allowed that communication the "test stats" was ok. I ran a diff on the postmaster log file from an "ok" run and a "failed" run and the only difference was the date/time, so there was no indication there of this type of problem there. Thanks, Mike Quinn >>> Tom Lane <[EMAIL PROTECTED]> 4/27/04 9:38:58 PM >>> "Mike Quinn" <[EMAIL PROTECTED]> writes: > [ $subject ] The stats collector isn't starting, but you're not showing any evidence to suggest why. Try looking in the postmaster log file for related error messages. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] make check regression "test stats" failed
Postgresql Version 7.4.2 Slackware 9.1 kernel 2.4.26 I did: ./configure make make check Here is the regression.diffs file: *** ./expected/stats.outFri Oct 31 19:18:20 2003 --- ./results/stats.out Wed Apr 21 09:41:57 2004 *** *** 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! t| t| t| t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, --- 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! f| f| f| f (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, *** *** 71,77 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! t| t (1 row) -- clean up --- 71,77 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! f| f (1 row) -- clean up == I also did: make install # and make a database and start the postmaster then make installcheck and got the same sort of results. If you need anymore information let me know. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] postgres-win32
I get this error when I try to initialise the database. Downloaded today from http://www.hagander.net/pgsql/win32snap/ C:\>initdb -V initdb (PostgreSQL) 7.5devel C:\>initdb -L "c:/progs/postgres/share" fgets failure: No error The program "postgres" was found by INITDB.EXE but was not the same version as " INITDB.EXE". Check your installation. C:\> -- *** Mike Evans Dept of Chemistry UMIST P.O. Box 88 Manchester M60 1QD Mobile: 07790 67 47 18 *** ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] beta - win32, restore from pg_dump not possible
Hello, Testing out beta version of 8.0 on XP Pro. I am trying to use psql to restore a dump of my database (prod. version runs under cygwin). Whenever I execute psql the password prompt is displayed and skipped right over which results in the command failing. psql.exe mydb < c:\mybackup file is the command I am executing. Even if I use the -U option it still prompts for a password and then automatically jumps to the next step without me having a chance to enter the password. Mike ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] 8.0 beta service won't start
Hi, We’ve been using Postgres for about a year. I recently installed the beta 8.0 Windows version on my XP laptop. It worked fine for about a week, but now the service will not start. Here’s the message I receive: Any ideas? Michael Hornick Insurance Systems Inc. [EMAIL PROTECTED] Free: 877-777-2231 Office: 416-249-2260 ext. 309 Cell: 416-704-9250 www.insurancesystems.ca <>
Re: [BUGS] 8.0 beta service won't start
Thanks guy's - I'll try it. Michael Hornick Insurance Systems Inc. [EMAIL PROTECTED] -Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: September 11, 2004 11:43 AM To: Bruce Momjian Cc: Mike Hornick; [EMAIL PROTECTED] Subject: SV: [BUGS] 8.0 beta service won't start >> This is almost certainly the "pid file does nto go away" >issue. Manually remove the .pid file in the data directory, >and start the service. >> >> I beleive this bug is fixed in beta-2. > >I think we fixed that after beta2. Oh, that might be so. Then let me rephrase - it's fixed in the MSI installers released after beta-2, because we waited for a couple of specific fixes before we made those (that's why they were aclled beta2-dev1 etc, and not plain beta-2) //Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Substring function incorrect when searching for '@.'
To reproduce: create a table with a data type of varchar (50) and name it email insert into this table the following values: [EMAIL PROTECTED] Execute the following statement: SELECT CASE WHEN count(substring(email FROM '@.')) > 0 THEN count(substring(email FROM '@.')) ELSE 0 END, email FROM your_schema.your_table GROUP BY email; Result with be equal to 1 / True. It should be 0 / False. If you execute the above but replace '@.' with '@a' it will also return 1 / True is correct. The only time it fails for me is if the @ is immediately followed by a period. 7.3.4 using psql via pgadminIII under cygwin. Mike ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] solaris 10 with gcc 3.3.2
Tom Lane wrote: I wrote: This is standard practice for gcc: it tries to use "cleaned up" versions of system headers that will not elicit useless warnings from gcc. It's a good idea, actually, because the degree of insanity in vendor-supplied system headers is pretty depressing. But if the gcc install process generated an invalid "cleanup" file then you need to take that up with the gcc boys, not us. On rereading this, a nearly-dead neuron fired --- I have seen problems of this sort arise when someone took a gcc installation generated on NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1, or indeed any release other than M.N. That nearly-dead neuron has value. The problem is that most people are getting the Solaris 10 beta builds whose headers conflict with the gcc 3.3.2 package's 'adapted' headers they are acquiring from sunfreeware.com, which, along with distributing other binary packages, is the place referred to by gcc.gnu.org for pre-built Solaris binaries. All the original poster needs to do is rebuild the gcc's 'adapted' headers with: # cd /usr/local/lib/gcc-lib/i386-pc-solaris2.10/3.3.2/install-tools # ./mkheaders and they should be good to go Mike Mascari ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] solaris 10 with gcc 3.3.2
Mike Mascari wrote: Tom Lane wrote: I wrote: This is standard practice for gcc: it tries to use "cleaned up" versions of system headers that will not elicit useless warnings from gcc. It's a good idea, actually, because the degree of insanity in vendor-supplied system headers is pretty depressing. But if the gcc install process generated an invalid "cleanup" file then you need to take that up with the gcc boys, not us. On rereading this, a nearly-dead neuron fired --- I have seen problems of this sort arise when someone took a gcc installation generated on NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1, or indeed any release other than M.N. That nearly-dead neuron has value. The problem is that most people are getting the Solaris 10 beta builds whose headers conflict with the gcc 3.3.2 package's 'adapted' headers they are acquiring from sunfreeware.com, which, along with distributing other binary packages, is the place referred to by gcc.gnu.org for pre-built Solaris binaries. All the original poster needs to do is rebuild the gcc's 'adapted' headers with: # cd /usr/local/lib/gcc-lib/i386-pc-solaris2.10/3.3.2/install-tools # ./mkheaders and they should be good to go Actually, I see the original poster is on SPARC, so the correct path to the 'mkheaders' utility is probably going to be: # cd /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/install-tools # ./mkheaders Mike Mascari ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] BUG #1414: DOC - pl/Perl hash tags missing
The following bug has been logged online: Bug reference: 1414 Logged by: Mike Blackwell Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.0 Operating system: N/A Description:DOC - pl/Perl hash tags missing Details: In the pl/Perl section of the 8.0.0 manual, as viewed on the postgresql.org web site, all perl code hash tags seem to be missing. i.e. $hashref-> displays as $hashref-> ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] /df doesn't work with pg_autovacuum
Mike Cox <[EMAIL PROTECTED]> writes: > When I have pg_autovacuum on, df doesn't work. When I turn it off, > /df works. ^ I have a typo in this message. \df doesn't work, when pg_autovacuum is on. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] /df doesn't work with pg_autovacuum
When I have pg_autovacuum on, df doesn't work. When I turn it off, /df works. The error message I get is "less is not found". In the pg_postgresql.conf I have these set as the README suggests: stats_start_collector = true stats_row_level = true Hope that helps. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1629: subquery IN returns incorrect results
The following bug has been logged online:
Bug reference: 1629
Logged by: mike g
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2000
Description:subquery IN returns incorrect results
Details:
If I run this query:
SELECT distinct CAST(newprogram as varchar(60)) FROM
(SELECT t.propnbr,
CASE WHEN t.propname = 'A' THEN 'Am'
WHEN t.propname = 'B' THEN 'AMm'
WHEN t.propname = 'C' THEN 'I might vanish'
WHEN t.propname = 'D' THEN 'Bem'
WHEN t.propname = 'E' THEN 'Cm'
WHEN t.propname = 'F' THEN 'Clm'
WHEN t.propname = 'G' THEN 'Com'
WHEN t.propname = 'H' THEN 'Dm'
WHEN t.propname = 'I' THEN 'Er'
WHEN t.propname = 'J' THEN 'Err'
WHEN t.propname = 'K' THEN 'Em'
WHEN t.propname = 'L' THEN 'Fm'
WHEN t.propname = 'M' THEN 'Fm'
WHEN t.propname = 'N' THEN 'Gm'
WHEN t.propname = 'O' THEN 'Hm'
WHEN t.propname = 'P' THEN 'Dm'
WHEN t.propname = 'Q' THEN 'Lm'
WHEN t.propname = 'R' THEN 'Nm'
WHEN t.propname = 'S' THEN 'Om'
WHEN t.propname = 'T' THEN 'Err'
WHEN t.propname = 'U' THEN 'Rm'
WHEN t.propname = 'V' THEN 'Tm'
WHEN t.propname = 'W' THEN 'Tm'
ELSE t.propname
END as newprogram
FROM example_data t
INNER JOIN example_data2 b ON t.propco = b.propco
WHERE
upper(b.serviced) = 'STATE1' and
t.propname in ('A',
'B'
'C', --switch me
'D', -- and switch me
'E',
'F',
'G',
'H',
'I',
'J',
'K',
'L',
'M',
'N',
'O',
'P',
'Q',
'R',
'S',
'T',
'U',
'V',
'W',
'X')) as my_data
My results are:
newprogram
Am
Bem
Clm
Cm
Com
Dm
Em
Er
Err
Fm
Gm
Hm
Lm
Nm
Om
Rm
Tm
If I just change the order of the data for the IN subquery portion
SELECT distinct CAST(newprogram as varchar(60)) FROM
(SELECT t.propnbr,
CASE WHEN t.propname = 'A' THEN 'Am'
WHEN t.propname = 'B' THEN 'AMm'
WHEN t.propname = 'C' THEN 'I might vanish'
WHEN t.propname = 'D' THEN 'Bem'
WHEN t.propname = 'E' THEN 'Cm'
WHEN t.propname = 'F' THEN 'Clm'
WHEN t.propname = 'G' THEN 'Com'
WHEN t.propname = 'H' THEN 'Dm'
WHEN t.propname = 'I' THEN 'Er'
WHEN t.propname = 'J' THEN 'Err'
WHEN t.propname = 'K' THEN 'Em'
WHEN t.propname = 'L' THEN 'Fm'
WHEN t.propname = 'M' THEN 'Fm'
WHEN t.propname = 'N' THEN 'Gm'
WHEN t.propname = 'O' THEN 'Hm'
WHEN t.propname = 'P' THEN 'Dm'
WHEN t.propname = 'Q' THEN 'Lm'
WHEN t.propname = 'R' THEN 'Nm'
WHEN t.propname = 'S' THEN 'Om'
WHEN t.propname = 'T' THEN 'Err'
WHEN t.propname = 'U' THEN 'Rm'
WHEN t.propname = 'V' THEN 'Tm'
WHEN t.propname = 'W' THEN 'Tm'
ELSE t.propname
END as newprogram
FROM example_data t
INNER JOIN example_data2 b ON t.propco = b.propco
WHERE
upper(b.serviced) = 'STATE1' and
t.propname in ('A',
'B'
'D', -- and switch me
'C', --switch me
'E',
'F',
'G',
'H',
'I',
'J',
'K',
'L',
'M',
'N',
'O',
'P',
'Q',
'R',
'S',
'T',
'U',
'V',
'W',
'X')) as my_data
Gives this for a result
Am
Clm
Cm
Com
Dm
Em
Er
Err
Fm
Gm
Hm
I might vanish
Lm
Nm
Om
Rm
Tm
I will email a pg_dump of the two tables on request.
The results of either version are incorrect.
If you remove the IN subquery and replace each case with t.propname = 'A'
or... then correct results returned:
AMm
Am
Bem
Clm
Cm
Com
Dm
Em
Er
Err
Fm
Gm
Hm
I might vanish
Lm
Nm
Om
Rm
Tm
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1629: subquery IN returns incorrect results
Sorry, I used the online bug reporting form and it doesn't have an option to attach a file to it. If it had I would have attached a pg_dump file. Mike On Wed, Apr 27, 2005 at 10:57:42AM -0400, Tom Lane wrote: > "mike g" <[EMAIL PROTECTED]> writes: > > Description:subquery IN returns incorrect results > > It's impossible to investigate this with the amount of information you > have provided. Please show a *self contained* example, including any > table declarations and test data needed. > > regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1629: subquery IN returns incorrect results
[snip]
You are correct about the comma missing between the B and C in the query. It is
turning it into B'C. I can't think of a good way for postgres to try and
generate a warning in case a typo like this is made.
Thank you.
Mike
>
> Unless this is a copy/paste error, you have missed a , in your query. Which
> effectively turns it into
> ('A', 'B''C', 'D' ...
>
> Which mean that switching those two will give incorrect results. One will be
> missing C, and it will be included with B,
> and the other D for the same reason.
>
> > 'C', --switch me
> > 'D', -- and switch me
> > 'E',
> > 'F',
> [snip]
>
> Regards
>
> Russell Smith.
>
> ---(end of broadcast)---
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] BUG #1635: Failed to create process for initdb
Did you remove the postgres user account before reinstalling? On Wed, Apr 27, 2005 at 06:49:59PM +0100, Tom wrote: > > The following bug has been logged online: > > Bug reference: 1635 > Logged by: Tom > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows 2000 > Description:Failed to create process for initdb > Details: > > I'm trying to reinstall PostgreSQL and during the install I'm getting the > following error. Then it shuts down the install. > > Failed to create process for initdb: Logon failure: unknown user name or bad > password > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1638: ODBC driver problem
I believe the ODBC package is managed by a different group. Bugs can be viewed and added here: http://gborg.postgresql.org/project/psqlodbc/bugs/buglist.php Mike On Fri, Apr 29, 2005 at 04:31:02PM +0100, Vig Sandor wrote: > > The following bug has been logged online: > > Bug reference: 1638 > Logged by: Vig Sandor > Email address: [EMAIL PROTECTED] > PostgreSQL version: ANY ( now: 8.0) > Operating system: ANY (XP, W2k, Linux...) > Description:ODBC driver problem > Details: > > Hi, > > I wrote an application (in Cbuilder 5, using BDE) > the was just working fine with the ODBC driver in > "psqlodbc-07_03_0200.zip". With the latest ODBC drivers > the program crashes after sending the first query. > (connect is successfull) It raises a null pointer > exception. After downgrading the ODBC driver, it's > all OK. I tested it with different servers, clients, > psql server versions, at home, at work, etc.. but > it was always the same. > > Please help. > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1988: keygen not implemented
The following bug has been logged online: Bug reference: 1988 Logged by: Mike Clements Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: WinXP Description:keygen not implemented Details: Create a table with an integer primary key using a sequence to automatically assign values. Connect to the database with a JDBC client. Insert a row into the table using: Connection.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); The driver throws an exception saying this method is not yet implemented. What it should do is create the prepared statement so when you execute it, the returned ResultSet has the generated primary key. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1988: keygen not implemented
Thanks for the info. I found a workaround by selecting the current value of the sequence after doing the insert. This however is not desirable since it requires another round trip call to the DB, and it requires PostGRE SQL specific code in my "generic" JDBC client. If the driver supported getGeneratedKeys(), client applications could perform better and be truly generic. Also looking at the release notes I see I'm not the only person asking for this feature... Good luck. > -Original Message- > From: Oliver Jowett [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 23, 2005 2:24 PM > To: Mike Clements > Cc: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #1988: keygen not implemented > > Mike Clements wrote: > > > Insert a row into the table using: > > Connection.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); > > The driver throws an exception saying this method is not > yet implemented. > > This is an optional part of the JDBC spec, and the driver > doesn't claim > to support it in the metadata it provides > (DatabaseMetaData.supportsGetGeneratedKeys() returns false). > > > What it should do is create the prepared statement so when > you execute it, > > the returned ResultSet has the generated primary key. > > Unfortunately this requires functionality in the backend that > does not > yet exist (support for "INSERT .. RETURNING ...", or similar). > > -O > > ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2000: psql does not prompt for password
I get the same thing with 8.0.4, on Windows XP Professional. ~Mike Bruce Momjian wrote: > Todd wrote: > > > > The following bug has been logged online: > > > > Bug reference: 2000 > > Logged by: Todd > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.1 Beta 4 > > Operating system: Windows Xp home > > Description:psql does not prompt for password > > Details: > > > > psql -U postgres does not prompt for password and responds with... > > > > psql: FATAL: password authentication failed for user "postgres". > > > > even when I pass the -W option it doesn't prompt for password and gives me > > the error above. I deleted and recreated my cluster and get the same > > result. I can connect to the database using PgAdmin as user postgres. > > I have no idea what is causing this, but I have never heard of this > problem before. > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2354: No admin rights, but still refuses to run
The following bug has been logged online: Bug reference: 2354 Logged by: Mike Haller Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3-1 Operating system: Windows 2000 Description:No admin rights, but still refuses to run Details: Hi Postgres-People, i have no admin rights. At least, I could not install PostgreSQL as System Service because he told me i have not enough permissions to do so. Still, postgres refuses to run because he thinks i have administrative permissions. You should really add an option, so users can start the server on their local machine. And yes, I have read the note on NOT to report the behaviour as bug. But since the installer tells me i'm not an Admin and Postgres tells me i am an Admin - this is a bug from users point of view. thanks Mike ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #5532: Valid UTF8 sequence errors as invalid
> > > > It is not valid. See http://tools.ietf.org/html/rfc3629 --- a sequence > beginning with ED must have a second byte in the range 80-9F to be > legal, and this doesn't. The example you give would decode as U+DF2D, > ie part of a surrogate pair, which is specifically disallowed in UTF8 > --- you're supposed to code the original character directly, not via a > surrogate pair. The primary reason for this rule is that otherwise > there are multiple ways to encode the same character, which can be a > security hazard. > > Thanks for the explanation. Unicode has always given me a hard time. > > You should file bugs against those tools. > > I certainly will. I apologize for filing the bug against postgres (I suppose the "voting" method of figuring out which piece software is the buggy one has failed me). I've run into a fair amount of unicode errors when trying to copy in log files. Would you recommend using bytea or another data type instead of text or varchar... or at least copying to a staging table with bytea's and filtering out invalid rows when moving it to the main table?
[BUGS] BUG #5534: IS DOCUMENT predicate errors instead of returning false
The following bug has been logged online: Bug reference: 5534 Logged by: Mike Fowler Email address: m...@mlfowler.com PostgreSQL version: 9.0beta2 Operating system: Linux 2.6.31-14-generic #48-Ubuntu SMP Description:IS DOCUMENT predicate errors instead of returning false Details: IS DOCUMENT should return false for a non-well formed document, and indeed is coded to do such. However, the conversion to the xml type which happens before the underlying xml_is_document function is even called fails and exceptions out. I've mentioned this on -hackers with message ID 20100701172553.w5vdy1xbocos8...@www.mlfowler.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5534: IS DOCUMENT predicate errors instead of returning false
Quoting Mike Fowler :
The following bug has been logged online:
Bug reference: 5534
Logged by: Mike Fowler
Email address: m...@mlfowler.com
PostgreSQL version: 9.0beta2
Operating system: Linux 2.6.31-14-generic #48-Ubuntu SMP
Description:IS DOCUMENT predicate errors instead of returning false
Details:
IS DOCUMENT should return false for a non-well formed document, and indeed
is coded to do such. However, the conversion to the xml type which happens
before the underlying xml_is_document function is even called fails and
exceptions out. I've mentioned this on -hackers with message ID
20100701172553.w5vdy1xbocos8...@www.mlfowler.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The attached patch is a very small patch that changes parse_expr.c to
not convert everything to xml. This now means that when passed
malformed XML it will return false instead of throwing an exception.
In my mind this acceptable as I don't see anywhere in the standard
that mandates that:
xmlval IS NOT DOCUMENT == xmlval IS CONTENT
Regards,
--
Mike Fowler
Registered Linux user: 379787
*** a/src/backend/parser/parse_expr.c
--- b/src/backend/parser/parse_expr.c
***
*** 1950,1956 transformXmlExpr(ParseState *pstate, XmlExpr *x)
Assert(false);
break;
case IS_DOCUMENT:
! newe = coerce_to_specific_type(pstate, newe, XMLOID,
"IS DOCUMENT");
break;
}
--- 1950,1956
Assert(false);
break;
case IS_DOCUMENT:
! newe = coerce_to_specific_type(pstate, newe, TEXTOID,
"IS DOCUMENT");
break;
}
*** a/src/backend/utils/adt/xml.c
--- b/src/backend/utils/adt/xml.c
***
*** 795,801 xmlvalidate(PG_FUNCTION_ARGS)
bool
! xml_is_document(xmltype *arg)
{
#ifdef USE_LIBXML
bool result;
--- 795,801
bool
! xml_is_document(text *arg)
{
#ifdef USE_LIBXML
bool result;
***
*** 805,811 xml_is_document(xmltype *arg)
/* We want to catch ereport(INVALID_XML_DOCUMENT) and return false */
PG_TRY();
{
! doc = xml_parse((text *) arg, XMLOPTION_DOCUMENT, true,
GetDatabaseEncoding());
result = true;
}
--- 805,811
/* We want to catch ereport(INVALID_XML_DOCUMENT) and return false */
PG_TRY();
{
! doc = xml_parse(arg, XMLOPTION_DOCUMENT, true,
GetDatabaseEncoding());
result = true;
}
*** a/src/include/utils/xml.h
--- b/src/include/utils/xml.h
***
*** 70,76 extern xmltype *xmlelement(XmlExprState *xmlExpr, ExprContext *econtext);
extern xmltype *xmlparse(text *data, XmlOptionType xmloption, bool preserve_whitespace);
extern xmltype *xmlpi(char *target, text *arg, bool arg_is_null, bool *result_is_null);
extern xmltype *xmlroot(xmltype *data, text *version, int standalone);
! extern bool xml_is_document(xmltype *arg);
extern text *xmltotext_with_xmloption(xmltype *data, XmlOptionType xmloption_arg);
extern char *escape_xml(const char *str);
--- 70,76
extern xmltype *xmlparse(text *data, XmlOptionType xmloption, bool preserve_whitespace);
extern xmltype *xmlpi(char *target, text *arg, bool arg_is_null, bool *result_is_null);
extern xmltype *xmlroot(xmltype *data, text *version, int standalone);
! extern bool xml_is_document(text *arg);
extern text *xmltotext_with_xmloption(xmltype *data, XmlOptionType xmloption_arg);
extern char *escape_xml(const char *str);
*** a/src/test/regress/expected/xml.out
--- b/src/test/regress/expected/xml.out
***
*** 357,362 SELECT xml 'bar' IS DOCUMENT;
--- 357,378
t
(1 row)
+ SELECT xml 'barbar'
+ barbarbarbarfoo' IS DOCUMENT;
?column?
--
***
*** 376,387 SELECT xml 'abc' IS NOT DOCUMENT;
(1 row)
SELECT '<>' IS NOT DOCUMENT;
ERROR: invalid XML content
! LINE 1: SELECT '<>' IS NOT DOCUMENT;
!^
! DETAIL: Entity: line 1: parser error : StartTag: invalid element name
! <>
! ^
SELECT xmlagg(data) FROM xmltest;
xmlagg
--
--- 392,418
(1 row)
SELECT '<>' IS NOT DOCUMENT;
+ ?column?
+ --
+ t
+ (1 row)
+
+ SELECT xml 'barbar'
! barbarbarbar' IS DOCUMENT;
+ SELECT xml 'barbarbarfoo' IS DOCUMENT;
SELECT xml '' IS NOT DOCUMENT;
SELECT xml 'abc' IS NOT DOCUMENT;
SELECT '<>' IS NOT DOCUMENT;
+ SELECT xml 'barbar
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5587: Installer non-default file association problem
The following bug has been logged online: Bug reference: 5587 Logged by: Mike Parfitt Email address: m_parf...@hotmail.com PostgreSQL version: 8.4.4.1 Operating system: Windows XP SP3 Description:Installer non-default file association problem Details: When the installer halts showing "Initialising the database cluster (this may take a few minutes)" message it may be because that PC has a non-default .bat file association. In my case, I used Process Explorer and looked at the other processes it had spawned :- postgresql-8.4.4-1-windows.exe cscript.exe UEDIT32.exe UEDIT32.EXE (UltraEdit) is my text editor of choice. Either the installer should test whether the .bat file association is going to start the right program, or the right program should be included in the parameter passed to the .Run function. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] LINE COMMAND
On 16/08/10 15:03, Felipe Lopes wrote: I would like to run a line command (psql) with the supplied password without pausing the command, but this option is not available: psql --username=root --password=root my_bd < "script.sql" The pass only can be informed after execution, pausing the command: psql --username=root --password my_bd Yes, the --password option forces the server to request password authentication. What you need to do is create a password file and specify --no-password on your psql command. See: http://www.postgresql.org/docs/8.4/interactive/libpq-pgpass.html Regards, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5623: xml2 and uuid-ossp contribs fail to compile
On 18/08/10 14:55, Jens Wilke wrote: The following bug has been logged online: Bug reference: 5623 Logged by: Jens Wilke Email address: jens.wi...@affinitas.de PostgreSQL version: 9.0b4 Operating system: Debian GNU/Linux Lenny Description:xml2 and uuid-ossp contribs fail to compile Details: Hi, to compile xml2 this link was necessary: ln -s /usr/include/libxml2/libxml ../../src/include I can't comment on uuid-ossp, but your XML problem sounds to me like libxml2 wasn't installed correctly. What parameters did you pass to configure? Could you build postgres with xml support? As in: path/to/pgsql/src> ./configure --with-libxml path/to/pgsql/src> make && make check Regards, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5745: geometry bug?
On 10/11/10 10:08, Jin wrote: The following bug has been logged online: Bug reference: 5745 Logged by: Jin Email address: jind...@gmail.com PostgreSQL version: 8.4.5 Operating system: windows xp pro sp3 Description:geometry bug? Details: The distance of the horizontal lseg and the point on that is inaccurate. select point(1.0,1.0)<-> lseg'(0.0,0.0),(2.0,0.0)'; ↓ result 1.4142135623731 must be 1.0 P.S. I'm sorry about if it was already reported. Because I can't read English well. From my digging it appears that this is returning the distance between the first point in the line and the individual point. To get 1.0 you would be looking for the the distance between the midpoint of the line and the individual point which can be achieved with: SELECT POINT(1.0,1.0) <-> POINT(LSEG'(0.0,0.0),(2.0,0.0)'); Digging through the documentation I can't find anything that says which point should be used in the line for distance comparisons. So I would rephrase this bug as: The distance of the horizontal lseg and the point is calculated against the first point in the line. Should this be calculated against the midpoint of the line instead? Regards, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5859: XML result in line and column
On 01/02/11 15:20, Alexandre wrote:
The following bug has been logged online:
Bug reference: 5859
Logged by: Alexandre
Email address: ultr...@gmail.com
PostgreSQL version: 8.4.7
Operating system: Windows 7
Description:XML result in line and column
Details:
The name of the xml tag is not being updated, becoming the first name
registry for all. Here is example:
Create table AUDITORIA_ANTERIOR
(
SEQUENCIA Serial NOT NULL,
SEQUENCIA_AUDITORIA Integer NOT NULL,
REGISTRO Text NOT NULL,
primary key (SEQUENCIA,SEQUENCIA_AUDITORIA)
);
insert into auditoria_anterior (sequencia_auditoria, registro)
values (1, '
123456789011FJOAO DA
SILVA ')
SELECT * FROM
xpath_table('sequencia',
'registro',
'auditoria_anterior',
'name(/ROOT/CLIENTES/*)|/ROOT/CLIENTES/*',
'sequencia = 1')
AS t(sequencia integer, coluna text, valor text)
--Incorrect result---
sequencia colunavalor
integer text text
--
1 CGC_CPF_CLIENTE 12345678901
1 CGC_CPF_CLIENTE 1
1 CGC_CPF_CLIENTE F
1 CGC_CPF_CLIENTE JOAO DA SILVA
Yep, I can duplicate this under Linux. However this is not a bug in
xpath_table. The problem is your XPath statement - the function name()
always returns the element name of the first element in a list. See
http://www.w3.org/TR/xpath/#section-Node-Set-Functions for details.
Unfortunately the only way to achieve what you want with with XPath 2.0
or XQuery, but libxslt (the underlying library executing the XPath) does
not and does not plan to support XPath 2.0 and PostgreSQL won't support
XQuery any time soon
(http://wiki.postgresql.org/wiki/XML_Support#Future_Projects).
Regards,
--
Mike Fowler
Registered Linux user: 379787
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5974: UNION construct type cast gives poor error message
On 13/04/11 19:32, Tom Lane wrote: "Jeff Wu" writes: The UNION construct (as noted on this page: http://www.postgresql.org/docs/9.0/static/typeconv-union-case.html) will cast unknown types to TEXT, however, if you try to do three or more UNIONs the order in which the UNIONs are executed will cause some columns to be cast to TEXT prematurely. The result is a type mismatch error. Or maybe we could find out that some other products do it like that despite what the spec says? regards, tom lane I happen to have a MS SQLServer 2008 instance at work as well as a MySQL 5.1 and an Oracle 10g. With the query: SELECT 1,null,null UNION SELECT 2,3,null UNION SELECT 3,null,4 In MS SQLServer I get (NB: no column headings): -- -- 1 | | 2 | 3 | 3 | | 4 In MySQL I get: 1 | NULL | NULL 1 | | 2 | 3 | 3 | | 4 In Oracle I get a delicious error message: Error: ORA-00923: FROM keyword not found where expected SQLState: 42000 ErrorCode: 923 Position: 19 Regards, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5974: UNION construct type cast gives poor error message
On 14/04/11 17:05, Kevin Grittner wrote:
SELECT 1,null,null FROM DUAL
UNION
SELECT 2,3,null FROM DUAL
UNION
SELECT 3,null,4 FROM DUAL
Sadly I can't profess to knowing Oracle, however if I run the query as
suggested I get:
1 | NULL | NULL
1 | |
2 | 3 |
3 | | 4
So to summarise, Oracle and PostgreSQL need minor tweaks to run cleanly
and SQLServer and MySQL do not. Given that the change for PostgreSQL is
so minor, I vote for changing the error message as Jeff suggests in the
interim to help users while the standards argument continues. Patch
attached.
Regards,
--
Mike Fowler
Registered Linux user: 379787
*** a/src/backend/parser/parse_coerce.c
--- b/src/backend/parser/parse_coerce.c
***
*** 1161,1167 select_common_type(ParseState *pstate, List *exprs, const char *context,
(errcode(ERRCODE_DATATYPE_MISMATCH),
/*--
translator: first %s is name of a SQL construct, eg CASE */
! errmsg("%s types %s and %s cannot be matched",
context,
format_type_be(ptype),
format_type_be(ntype)),
--- 1161,1167
(errcode(ERRCODE_DATATYPE_MISMATCH),
/*--
translator: first %s is name of a SQL construct, eg CASE */
! errmsg("%s types %s and %s cannot be matched. HINT: Postgres casts unknown types to TEXT by default.",
context,
format_type_be(ptype),
format_type_be(ntype)),
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6056: sorting issues
The following bug has been logged online:
Bug reference: 6056
Logged by: Mike Hepworth
Email address: michael.w.hepwo...@gmail.com
PostgreSQL version: 8.4
Operating system: Ubuntu 10.4
Description:sorting issues
Details:
Have database that is utf-8 encoding so that I can support both english,
french, and spanish. Having problems with the ordering of data.
I execute the following sql statment:
select * from (values('HALL, ANDY'),('HALLBERG, FRANK'),('HALLDEN,
DOUGLAS'),('HALL, DOUGLAS') ) x ORDER BY 1;
and get the following results
HALL, ANDY
HALLBERG, FRANK
HALLDEN, DOUGLAS
HALL, DOUGLAS
Please Help...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6122: Installation fails: "database cluster initialisation failed"
The following bug has been logged online: Bug reference: 6122 Logged by: Mike Holywell Email address: m...@segment8.co.uk PostgreSQL version: 9.0.4 Operating system: Mac OSX 10.7 (Lion) Description:Installation fails: "database cluster initialisation failed" Details: On a fresh install of Lion (11A511) installing Postgres 9.0.4 fails Problem running post-install step installation may not complete correctly The database cluster initialisation failed This has been reported on other blogs eg http://seeboriscode.blogspot.com/2011/06/osx-107-lion-postgres-installation. html I've had a similar(?) problem with the dscl command not creating the user under earlier Lion Betas -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
This can be closed. I figured out what I was doing wrong, which was after the conversion I was cleaning up the old datadir by deleting it, which destroyed the hard links to the data since I am using pg_upgrade --link Mike Wilson On Jul 12, 2012, at 3:49 PM, Bruce Momjian wrote: > On Thu, Jul 12, 2012 at 06:44:06PM -0400, Tom Lane wrote: >> mfwil...@gmail.com writes: >>> This runs without errors and I am able to start the new upgraded PG92beta2 >>> cluster. The schemas appear to be correct as well as the table definitions >>> and other schema objects. The tables themselves though are all empty. >> >> Hmm, maybe it's confused about XID past/future? Could we see the output >> of pg_controldata for both old and new clusters? > > Uh, I thought we only changfed the xlog stuff in 9.3, not 9.2, so I am > confused what would have changed in that area. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
I've had some time to examine this closer over the weekend. It appears that
pg_upgrade for 9.2b2 segfaults which more than likely has something to do with
the resulting converted database appearing to have no rows. Earlier in this
thread I reported that I was able to get the upgrade to work and this thread to
be closed but I was in error. At the time I was also testing with the 9.1.4
pg_upgrade which does work and I thought that I had a successful 9.2b2
pg_upgrade run. Apologies for the confusion and let me know if you would like
me to start a new thread.
...
pg_toast.pg_toast_948075_index: 948081 to 948081
c0.page_metadata_values_pkey: 948082 to 948082
c0.i_page_metadata_values_short_name: 948084 to 948084
Segmentation Fault (core dumped)
root@db4 /
My upgrade procedure is scripted and I hadn't noticed the core dump when I
first reported the bug. Here are the parameters of the run:
su - postgres -c "pg_upgrade --verbose --link \
--old-datadir=/opt/postgres/db/root/old --new-datadir=/opt/postgres/db/root/new
--old-bindir=${OLDPG}/bin/64/ \
--new-bindir=${NEWPG}/bin/ --old-port=5432 --new-port=5920 --user=postgres"
As a test I have also been using the pg_upgrade from 9.1.4 which does work:
…
relname: pg_toast.pg_toast_948075: reloid: 948079 reltblspace:
relname: pg_toast.pg_toast_948075_index: reloid: 948081 reltblspace:
relname: c0.page_metadata_values_pkey: reloid: 948082 reltblspace:
relname: c0.i_page_metadata_values_short_name: reloid: 948084 reltblspace:
Database: postgres
relname: pg_catalog.pg_largeobject: reloid: 2613 reltblspace:
relname: pg_catalog.pg_largeobject_loid_pn_index: reloid: 2683 reltblspace:
Database: template1
relname: pg_catalog.pg_largeobject: reloid: 2613 reltblspace:
relname: pg_catalog.pg_largeobject_loid_pn_index: reloid: 2683 reltblspace:
executing: SELECT spclocation FROMpg_catalog.pg_tablespace WHERE
spcname != 'pg_default' AND spcname != 'pg_global'
…
I've also tried a step-wise migration by first converting to PG914 and then to
PG92b2. This also fails with a similar segfault after the
c0.i_page_metadata_values_short_name index.
Of possible note in this DB is that the previous DBA renamed the "postgres"
user. As part of this conversion process I am renaming it back to it's
default. I'm doing this before running pg_upgrade:
# shift jibjab su (postgres) account back to postgres rolname
su - postgres -c "psql -U jibjab c0 -c \"update pg_authid set
rolname='postgres' where oid=10;\""
This probably isn't an issue as the 9.1.4 conversion works but I thought I
should at least mention it. Actually I don't think pg_upgrade will run
correctly if there isn't a postgres user so I imagine I need to correct this
issue before running the upgrade procedure anyway.
For now I am stymied in my attempt to upgrade and may have to look at trying to
get the non-link version of the upgrade working. That would be relatively
painful though as this upgrade will be for a commercial internet site that
can't easily tolerate a long down and the production DB is over a TB in size.
I am really looking forward to 9.2's index only scans due to the size of the
DB!
Cheers and thanks for any information you have on the issue.
Mike Wilson
mfwil...@gmail.com
On Jul 12, 2012, at 6:52 PM, Bruce Momjian wrote:
> On Thu, Jul 12, 2012 at 05:21:31PM -0700, Mike Wilson wrote:
>> This can be closed. I figured out what I was doing wrong, which was
>> after the conversion I was cleaning up the old datadir by deleting it,
>> which destroyed the hard links to the data since I am using pg_upgrade
>> --link
>
> Uh, actually, a hard link has two directory entries pointing to the same
> file, so you can delete the old datadir and the new datadir should not
> be affected.
>
> --
> Bruce Momjian http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
core stack: root@db4 / $ pstack ~postgres/core core '/opt/postgres/core' of 19868: pg_upgrade --verbose --link --old-datadir=/opt/postgres/db/root/old -- fd7ffeda1148 memcpy () + 6b8 0040b8b6 transfer_single_new_db () + fa 0040b6ea transfer_all_new_dbs () + 116 0040ae62 main () + 106 0040580c () As to the ownership, the bash script I am testing 9.1.4 and 9.2.0 with recursively chowns the directory that owns the old and the new PGDATA directory before running pg_upgrade. Mike Wilson mfwil...@gmail.com On Jul 15, 2012, at 2:45 PM, Tom Lane wrote: > Mike Wilson writes: >> I've had some time to examine this closer over the weekend. It >> appears that pg_upgrade for 9.2b2 segfaults which more than likely has >> something to do with the resulting converted database appearing to >> have no rows. > > Yeah, more than likely :-(. Could we see a stack trace from the > segfault? > >> Of possible note in this DB is that the previous DBA renamed the >> "postgres" user. > > Hmm. There is a known bug in beta2 that's triggered by old and new > clusters not having the same name for the bootstrap superuser; although > I don't recall that the symptoms included a segfault. In any case, > I'd suggest making sure the new cluster is initdb'd under the same > account that currently owns the old cluster. > > regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
Just for my interest I also created a new PG 842 db (initdb) and put some sample data it it and successfully did a pg_upgrade from 842 -> 920b2. Whatever the issue is it seems to be related to my actual database as a sample db conversion works. Again, 842-914 conversion works for my db though so possibly it was some change that happened to pg_upgrade since 914 was released that is having poor interaction with my actual db cluster. Also, I wanted to make sure I wasn't using some git checkout of 920 I downloaded the postgresql-9.2.beta2.tgz from the PostgreSQL site dir-browser and re-compiled. Still have the problem unfortunately. Cheers. Mike Wilson mfwil...@gmail.com On Jul 15, 2012, at 2:45 PM, Tom Lane wrote: > Mike Wilson writes: >> I've had some time to examine this closer over the weekend. It >> appears that pg_upgrade for 9.2b2 segfaults which more than likely has >> something to do with the resulting converted database appearing to >> have no rows. > > Yeah, more than likely :-(. Could we see a stack trace from the > segfault? > >> Of possible note in this DB is that the previous DBA renamed the >> "postgres" user. > > Hmm. There is a known bug in beta2 that's triggered by old and new > clusters not having the same name for the bootstrap superuser; although > I don't recall that the symptoms included a segfault. In any case, > I'd suggest making sure the new cluster is initdb'd under the same > account that currently owns the old cluster. > > regards, tom lane
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
Given the stack trace previously supplied and that the pg_upgrade from 9.1.4 does actually complete successfully can you recommend how I might continue to diagnose the issue myself? Since the 9.1.4 version of pg_upgrade did work I've started to look at the source for pg_upgrade in an attempt to see if the 9.1.4 version of the tool could be used instead of the 9.2.0 version. Due to the # of differences in the pg_upgrade source though a port seems unlikely. Can I get the git version string of the PG source you used for the version of the source that you tested with? I'd like to make sure that I'm using the same version as your successful test. Thanks. Mike Wilson mfwil...@gmail.com On Jul 17, 2012, at 4:39 PM, Bruce Momjian wrote: > On Tue, Jul 17, 2012 at 04:01:08PM -0700, Mike Wilson wrote: >> Please find below the full pg_upgrade output. Let me know if there are any >> other questions that I may have missed. Note, the attached pg_upgrade >> stdout log is for the schema only pg_dumpall upgrade attempt from PG842 -> >> PG920b2. >> > >> -rw-r--r-- mwilson/staff 314381 2012-07-17 18:57 pg842_pg_upgrade.log > > FYI, I was supplied with an anonymous SQL dump of the database and was > unable to reproduce the failure on Debian. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. +
Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
Tom, after patching pg_upgrade now runs successfully. I noticed that this patch had been applied since yesterday to the REL9_2_STABLE so I also tested with a git pull without the patch that appears to work also. I think issue has been resolved for me, thanks so much! You guys rock! Mike Wilson mfwil...@gmail.com On Jul 17, 2012, at 9:31 PM, Tom Lane wrote: > Bruce Momjian writes: >> I am using git head for testing. Tom sees a few things odd in >> load_directory() that might be causing some problems on Solaris, and >> this is new code for 9.2 for Solaris, so that might explain it. I think >> we need Tom to finish and then if you can grab our git source and test >> that, it would be great! > > The only thing I see that looks likely to represent a platform-specific > issue is the entrysize calculation. Mike, just out of curiosity, could > you see if the attached patch makes things better for you? > > regards, tom lane > > diff --git a/contrib/pg_upgrade/file.c b/contrib/pg_upgrade/file.c > index > 1dd3722142c9e83c1ec228099c3a3fd302a2179b..c886a67df43792a1692eec6b3b90238413e9f844 > 100644 > *** a/contrib/pg_upgrade/file.c > --- b/contrib/pg_upgrade/file.c > *** load_directory(const char *dirname, stru > *** 259,265 > return -1; > } > > ! entrysize = sizeof(struct dirent) - sizeof(direntry->d_name) + > strlen(direntry->d_name) + 1; > > (*namelist)[name_num] = (struct dirent *) malloc(entrysize); > --- 259,265 > return -1; > } > > ! entrysize = offsetof(struct dirent, d_name) + > strlen(direntry->d_name) + 1; > > (*namelist)[name_num] = (struct dirent *) malloc(entrysize); -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] initdb.exe changes --locale option
I'm using the "postgresql-9.2.0-1-windows.exe" installer, from Enterprise DB, on a Windows Vista 32-bit computer. The issue was noticed with the GUI installer, where I chose the local option "English, New Zealand" from a drop-down menu, but the resulting database cluster has "English_United States.1252". With initdb.exe, I see that --locale has unexpected behaviour. I'll present a few examples that each represent key : value, where key is set with --local="key" and value is from the output: The database cluster will be initialized with locale "value". C : C English : English_United States.1252 French : French_France.1252 nonsense : English_United Kingdom.1252 French, Canada : French_France.1252 French_Canada : French_Canada.1252 English, Canada : English_United States.1252 English_New_Zealand : English_United Kingdom.1252 English, New Zealand : English_United States.1252 English_New Zealand : English_New Zealand.1252 There are some interesting interpretations in the above, but I understand they probably depend on the OS (Windows Vista, in this case). In the install-postgresql.log file I see attempts to get a list of available system locales: Executing C:\Users\mwtoews\AppData\Local\Temp\postgresql_installer\getlocales.exe Script exit code: 0 Script output: AfrikaansxxCOMMASPxxSouthxxSPxxAfrica=Afrikaans, South Africa AlbanianxxCOMMASPxxAlbania=Albanian, Albania ... EnglishxxCOMMASPxxCanada=English, Canada ... EnglishxxCOMMASPxxNewxxSPxxZealand=English, New Zealand ... EnglishxxCOMMASPxxUnitedxxSPxxKingdom=English, United Kingdom EnglishxxCOMMASPxxUnitedxxSPxxStates=English, United States ... FrenchxxCOMMASPxxCanada=French, Canada FrenchxxCOMMASPxxFrance=French, France where it appears that the value after "=" is used to populate the drop-down menu. -Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] initdb.exe changes --locale option
Furthermore, to compare with initdb.exe from 9.1 on the same computer, here are the key : value pairs from the --locale="key" and locale used. >"C:\Program Files\PostgreSQL\9.1\bin\initdb.exe" --version initdb (PostgreSQL) 9.1.4 C : C English : English French : French nonsense : English_United Kingdom.1252 French, Canada : French, Canada French_Canada : French_Canada English, Canada : English, Canada English_New_Zealand : English_United Kingdom.1252 English, New Zealand : English, New Zealand English_New Zealand : English_New Zealand -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7530: initdb.exe ignores --locale option, uses "English_United States.1252"
Apologies for multiple email threads, as this message was sent before my other email and before adding my account to this list. This bug report is slightly misleading, as the --locale option is not ignored by initdb.exe, but is misinterpreted in certain cases. See email thread: "initdb.exe changes --locale option" http://archives.postgresql.org/pgsql-bugs/2012-09/msg00083.php -Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] initdb.exe changes --locale option
Testing on another Windows OS, here is a similar key : value exercise, described previously. The system is Windows 7 64-bit, with a system locale: "en-nz;English (New Zealand)" (from systeminfo.exe). The version of initdb.exe is 9.2.0, and the full command-line is: >"C:\Program Files\PostgreSQL\9.2\bin\initdb.exe" --locale="key" >--encoding=UTF-8 -D NUL C : C English : English_United States.1252 French : French_France.1252 nonsense : English_New Zealand.1252 displays initdb: invalid locale name "nonsense" 6 times French, Canada : French_France.1252 French_Canada : French_Canada.1252 English, Canada : English_United States.1252 English_New_Zealand : English_New Zealand.1252 displays initdb: invalid locale name "English_New_Zealand" 6 times English, New Zealand : English_United States.1252 English_New Zealand : English_New Zealand.1252 Interestingly, this OS displays "initdb: invalid locale name" (six times), whereas I don't recall seeing that message with Vista. But it doesn't tell me that "English, New Zealand" is invalid, while it changes the locale to "English_United States.1252", which is puzzling. -Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] initdb.exe changes --locale option
I've found a general solution: with the locale string, replace the first ", " (comma space) with "_". Around line 33 of initcluster.vbs, add: strLocale = Replace(strLocale,", ","_",1,1) I think it is fine to show "English, New Zealand" in the drop-down menu for the GUI installer, but initcluster.vbs needs to do the replacement to "English_New Zealand" in order to fulfil the correct initialisation. My testing was conducted using a Python script http://pastebin.com/9epyWz7x which produces a tab delimited table of input locales, and the locale chosen by initdb.exe, as well as the default language for text search configuration. The results from 200 locales shows some significant problems with locale detection, such that most "Language, Country" are substituted with only one country (you will pick up the pattern if you look at the data). Secondly, there are cases that are completely off: "Tamazight (Latin), Algeria" : "English_United Kingdom.1252", which is corrected to "Tamazight (Latin)_Algeria.1252" with the proper substitution. However, there are three corner cases (of 200) that either sort-of breaks things, or doesn't resolve anything: Original: Chinese (Traditional), Macao S.A.R. : Chinese (Traditional)_Taiwan.950 Replaced: Chinese (Traditional)_Macao S.A.R. : English_United Kingdom.1252 Original: Lao, Lao P.D.R. : Lao_Lao P.D.R..1252 Replaced: Lao_Lao P.D.R. : English_United Kingdom.1252 Original: Norwegian (Bokmål), Norway : English_United Kingdom.1252 Replaced: Norwegian (Bokmål)_Norway : English_United Kingdom.1252 (Note: I'm testing on a Windows Vista computer from the UK) Lastly, I had a look at the source code initdb.c, which appears to assume only POSIX locale of the format: [language[_territory][.codeset][@modifier]] E.g., see find_matching_ts_config, which assumes this locale format: http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/initdb/initdb.c;h=824c7fa7e4c76e0a3b8204ce0cdd21564f23d5df;hb=HEAD#l886 It should probably handle the WIN32 logic separately from POSIX locales, but that's a deeper matter. -Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Mixed newlines in Windows installer files
Apologies that this report is near trivial, and only concerns the Windows installers by EnterpriseDB (I'm not sure where else to post these). With all of the current EnterpriseDB builds for Windows, several files have inconsistent line endings, switching between so-called DOS (CR+LF) and UNIX (LF). scripts\serverctl.vbs scripts\runpsql.bat installer\server\*.vbs With all of these files, the header looks odd, e.g., serverctl.vbs in VIM: ' Copyright (c) 2012, EnterpriseDB Corporation. All rights reserved On Error Resume Next^M ^M ... or in notepad.exe (a terrible, yet default editor): ' Copyright (c) 2012, EnterpriseDB Corporation. All rights reservedOn Error Resume Next ... I've found this problem with 9.2 and in recent 9.1 installer directories, but not in older releases from a few months ago, so this is a recent change. (Even more nitpickier, pg_env.bat ends with lots of extra whitespace, but no line ending.) Note that mixed newlines do not appear to change their behaviour, but I could be mistaken. -Mike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
