[BUGS] Can not build libpq.dll with BCC
Hi! I filled out the bug form but I don't see my report appear in bug archive. Hence I am resorting to pgsql-bug list. Regards, CN OS: Win98 on top of win4lin on top of Linux Compiler BC++ 5.6.4 Possible bug 1: Unless lines 142 and 143 in ~/interfaces/libpq/bcc32.mak are changed to as the following, make aborts when copying: pthread.h: pthread-win32.h copy pthread-win32.h pthread.h Possible bug 2: With lines 142 and 143 in bcc32.mak changed to the above lines, make still fails with the messages: MAKE Version 5.2 Copyright (c) 1987, 2000 Borland Building the Win32 DLL and Static Library... No configuration specified. Defaulting to Release. echo #define SYSCONFDIR pg_config_paths.h #define SYSCONFDIR pg_config_paths.h bcc32.exe @MAKE0002.@@@ Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland ..\..\port\getaddrinfo.c: Warning W8017 ..\..\include\port/win32.h 46: Redefinition of 'DLLIMPORT' is not identical Warning W8017 ..\..\include\port/win32.h 149: Redefinition of 'SIGUSR1' is not identical Warning W8017 ..\..\include\port/win32.h 150: Redefinition of 'SIGUSR2' is not identical Error E2451 ..\..\port\getaddrinfo.c 245: Undefined symbol 'WSA_NOT_ENOUGH_MEMORY' in function pg_getaddrinfo Error E2451 ..\..\port\getaddrinfo.c 335: Undefined symbol 'WSA_NOT_ENOUGH_MEMORY' in function pg_gai_strerror Error E2451 ..\..\port\getaddrinfo.c 404: Undefined symbol 'WSA_NOT_ENOUGH_MEMORY' in function pg_getnameinfo Error E2451 ..\..\port\getaddrinfo.c 417: Undefined symbol 'WSA_NOT_ENOUGH_MEMORY' in function pg_getnameinfo *** 4 errors in Compile *** ** error 1 ** deleting ".\Release\getaddrinfo.obj" -- http://www.fastmail.fm - The way an email service should be ---(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] Can not build libpq.dll with BCC
> Error E2451 ..\..\port\getaddrinfo.c 245: Undefined symbol > 'WSA_NOT_ENOUGH_MEMORY' in function pg_getaddrinfo Error > E2451 ..\..\port\getaddrinfo.c 335: Undefined symbol > 'WSA_NOT_ENOUGH_MEMORY' in function pg_gai_strerror Error > E2451 ..\..\port\getaddrinfo.c 404: Undefined symbol > 'WSA_NOT_ENOUGH_MEMORY' in function pg_getnameinfo Error > E2451 ..\..\port\getaddrinfo.c 417: Undefined symbol > 'WSA_NOT_ENOUGH_MEMORY' in function pg_getnameinfo > *** 4 errors in Compile *** > > ** error 1 ** deleting ".\Release\getaddrinfo.obj" This sounds like you need a newer Platform SDK. This define should be in winsock2.h, per http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock /winsock/windows_sockets_error_codes_2.asp. Probably your includes from BCC are too old and needs updating. //Magnus ---(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
[BUGS] BUG #1913: select into a table missing a row part 2
The following bug has been logged online: Bug reference: 1913 Logged by: Keith Randall Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1beta2 Operating system: Linux 2.4.21-15 Redhat enterprise Description:select into a table missing a row part 2 Details: I'm missing a row when I generate a table off a view. select count(*) from foo; 20811 select * into temp from foo; select count(*) from temp; 20810 I have scripts that you can run to replicate at https://www.oas.ca/~randallk/pgbug.tar.bz2 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #1912: select into a table missing a row
The following bug has been logged online: Bug reference: 1912 Logged by: Keith Randall Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1beta2 Operating system: Linux 2.4.21-15 Redhat enterprise Description:select into a table missing a row Details: I'm missing a row when I generate a table off a view. select count(*) from foo; 20811 select * into temp from foo; select count(*) from temp; 20810 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #1914: Corrupted Table
The following bug has been logged online: Bug reference: 1914 Logged by: Cris Gamboa Email address: [EMAIL PROTECTED] PostgreSQL version: not sure Operating system: Redhat Linux 9 Description:Corrupted Table Details: Hi, we are newly using PostGre and after a few months that it was running well, the OS suddenly was corrupted destroying some of our tables. Is there any tool that we can use to restore our files back? Or at least get a portion of it? coz pgadmin cant seem to connect to the tables anymore. Thanks. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1913: select into a table missing a row part 2
On Tue, Sep 27, 2005 at 09:17:18AM +0100, Keith Randall wrote: > I'm missing a row when I generate a table off a view. > > select count(*) from foo; > > 20811 > > select * into temp from foo; > select count(*) from temp; > > 20810 Interesting. I can duplicate this behavior here. However, what's even more interesting, is that 8.0 returns 20814 rows in both cases, so something _is_ wrong. It may be related to the latest outer join bug, which Tom Lane fixed yesterday or the day before. I'll recompile and retest. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "Uno combate cuando es necesario... ¡no cuando está de humor! El humor es para el ganado, o para hacer el amor, o para tocar el baliset. No para combatir." (Gurney Halleck) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1913: select into a table missing a row part 2
Alvaro Herrera <[EMAIL PROTECTED]> writes: > It may be related to the latest outer join bug, which Tom Lane fixed > yesterday or the day before. I'll recompile and retest. That was my first thought also. Does the plan for the select-from-view involve a hash join? Have you finished testing with CVS tip yet? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1913: select into a table missing a row part 2
On Tue, Sep 27, 2005 at 10:37:06AM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > It may be related to the latest outer join bug, which Tom Lane fixed > > yesterday or the day before. I'll recompile and retest. > > That was my first thought also. Does the plan for the select-from-view > involve a hash join? Have you finished testing with CVS tip yet? Yes, it does involve hash joins, and yes I did test CVS tip, and the problem doesn't happen there; or at least I can't reproduce it. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34 "Everybody understands Mickey Mouse. Few understand Hermann Hesse. Hardly anybody understands Einstein. And nobody understands Emperor Norton." ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #1883: Renaming a schema leaves inconsistent
Bruce Momjian writes:
> With the following errors caused by ALTER SCHEMA RENAME, I recommend we
> remove this feature for 8.1 and revisit it for 8.2.
It's a mistake to blame ALTER SCHEMA RENAME for this problem, as you can
cause it equally well by renaming the sequence itself, or by moving it
into another schema with ALTER TABLE SET SCHEMA. Will you also insist
on disabling the latter new feature?
I experimented a little bit with defining nextval() and friends as
taking "regclass" instead of text, and it seems like that works pretty
nicely for these problems, once you've got the literal in the form of
regclass (ie, internally an OID). For actual SERIAL columns that
doesn't seem like a big deal, because the default expression doesn't
appear literally in dumps (at least not dumps made with a recent version
of pg_dump). All we'd have to do is tweak the parser to generate a call
to nextval(regclass) instead of nextval(text) when expanding SERIAL.
For dumps that contain explicit calls, like
keycol int default nextval('foo'::text)
I really don't think there is anything much we can do :-( except to
recommend that people update the default expressions. You'd need to
change it to
keycol int default nextval('foo'::regclass)
to be safe against renamings of 'foo', and I don't see any very good
way to force that to happen automatically.
I think that a reasonable answer for 8.1 would be to add
nextval(regclass) (and I guess parallel versions of currval and setval,
too), leaving the existing text-based functions available, and modifying
the parser to use nextval(regclass) instead of nextval(text) in SERIAL
defaults.
In the long run it would be nice to deprecate and eventually remove
the text-based functions, but I don't see how to do that in the short
run without introducing an implicit text-to-regclass cast for
compatibility purposes. That seems a bit risky.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] BUG #1883: Renaming a schema leaves inconsistent
Tom Lane wrote:
> Bruce Momjian writes:
> > With the following errors caused by ALTER SCHEMA RENAME, I recommend we
> > remove this feature for 8.1 and revisit it for 8.2.
>
> It's a mistake to blame ALTER SCHEMA RENAME for this problem, as you can
> cause it equally well by renaming the sequence itself, or by moving it
> into another schema with ALTER TABLE SET SCHEMA. Will you also insist
> on disabling the latter new feature?
Sure. (Silly question, silly answer.)
Seriously, you have to consider the likelihood of breakage, and the
surprise factor. If someone moves a sequence to another schema or
renames it, they would assume breakage, but moving all tables/sequences
together would not suggest sequence breakage.
So, below, you are saying that once 8.0.X dumps are loaded into 8.1,
that the renaming of those schemas would succeed, at least for SERIAL,
but not for manual sequence defaults. That seems OK, I guess, in the
hope that people who are creating defaults manually based on sequences
are going to know how to fix things.
---
> I experimented a little bit with defining nextval() and friends as
> taking "regclass" instead of text, and it seems like that works pretty
> nicely for these problems, once you've got the literal in the form of
> regclass (ie, internally an OID). For actual SERIAL columns that
> doesn't seem like a big deal, because the default expression doesn't
> appear literally in dumps (at least not dumps made with a recent version
> of pg_dump). All we'd have to do is tweak the parser to generate a call
> to nextval(regclass) instead of nextval(text) when expanding SERIAL.
>
> For dumps that contain explicit calls, like
> keycol int default nextval('foo'::text)
> I really don't think there is anything much we can do :-( except to
> recommend that people update the default expressions. You'd need to
> change it to
> keycol int default nextval('foo'::regclass)
> to be safe against renamings of 'foo', and I don't see any very good
> way to force that to happen automatically.
>
> I think that a reasonable answer for 8.1 would be to add
> nextval(regclass) (and I guess parallel versions of currval and setval,
> too), leaving the existing text-based functions available, and modifying
> the parser to use nextval(regclass) instead of nextval(text) in SERIAL
> defaults.
>
> In the long run it would be nice to deprecate and eventually remove
> the text-based functions, but I don't see how to do that in the short
> run without introducing an implicit text-to-regclass cast for
> compatibility purposes. That seems a bit risky.
>
> regards, tom lane
>
--
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 6: explain analyze is your friend
Re: [HACKERS] [BUGS] BUG #1883: Renaming a schema leaves inconsistent
With the following errors caused by ALTER SCHEMA RENAME, I recommend we
remove this feature for 8.1 and revisit it for 8.2. I would just remove
the grammar construct for it and the documentation.
To fix this, we would need to redesign the way we store DEFAULT sequence
assignments, and I don't think that is a good thing to do during beta.
I see people wanting bitmapped scans ASAP, not renaming of schemas. Our
beta time is better spent on other things than getting this to work now.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > This item has been added to the 8.1 bugs list:
> > > http://momjian.postgresql.org/cgi-bin/pgbugs
> >
> > This isn't going to be fixed for 8.1. I think it's really a variant of
> > the TODO item
> > o %Have ALTER TABLE RENAME rename SERIAL sequence names
>
> Well, it might be a variant, but its failure is much worse. For a table
> rename, you just get a strange \d display:
>
> test=> CREATE TABLE test (x SERIAL);
> NOTICE: CREATE TABLE will create implicit sequence "test_x_seq" for
> serial column "test.x"
> CREATE TABLE
> test=> ALTER TABLE test RENAME TO test2;
> ALTER TABLE
> test=> INSERT INTO test2 VALUES (DEFAULT);
> INSERT 0 1
> test=> \d test2
> Table "public.test2"
>Column | Type | Modifiers
> +-+-
>x | integer | not null default nextval('public.test_x_seq'::text)
>
> The insert into the table still works. For the schema rename, the
> insert into the table doesn't work anymore. The odds that a schema
> rename is going to have _no_ sequence dependencies in the same schema
> seems pretty unlikely, meaning rename schema is almost guarantted to
> create some broken table defaults. With this behavior, if we can't fix
> it in 8.1, I am wonderingf we should just disable the feature:
>
> test=> CREATE SCHEMA aa;
> CREATE SCHEMA
> test=> CREATE TABLE aa.test (x SERIAL);
> NOTICE: CREATE TABLE will create implicit sequence "test_x_seq" for
> serial column "test.x"
> CREATE TABLE
> test=> ALTER SCHEMA aa RENAME TO bb;
> ALTER SCHEMA
> test=> INSERT INTO bb.test VALUES (DEFAULT);
> ERROR: SCHEMA "aa" does NOT exist
> test=> \d bb.test
> Table "bb.test"
>Column | Type |Modifiers
> +-+-
>x | integer | not null default nextval('aa.test_x_seq'::text)
>
> --
> 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
>
--
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 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #1916: selection criteria from one outer join on clause applied to other joins
The following bug has been logged online:
Bug reference: 1916
Logged by: Kevin Grittner
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1beta2
Operating system: Linux and Windows
Description:selection criteria from one outer join on clause applied
to other joins
Details:
Below is a much simplified test case. In the real application, it actually
makes sense for the framework code to combine selection criteria from
multiple sources to limit the outer join and let the database perform the
set logic.
Obviously, adding an outer join to a query which is already returning rows
should never reduce the number of rows returned.
dtr=> create table t1 (f1 smallint not null, f2 smallint not null, primary
key (f1, f2));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" for
table "t1"
CREATE TABLE
dtr=> create table t2 (f1 smallint not null, f2 smallint not null, f3
smallint not null, f4 varchar(10), primary key (f1, f2, f3));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t2_pkey" for
table "t2"
CREATE TABLE
dtr=> insert into t1 values (1, 10);
INSERT 0 1
dtr=> insert into t1 values (1, 20);
INSERT 0 1
dtr=> insert into t1 values (2, 10);
INSERT 0 1
dtr=> insert into t1 values (2, 20);
INSERT 0 1
dtr=> insert into t2 values (1, 20, 100, 'xxx');
INSERT 0 1
dtr=> select t1.* from t1
dtr-> left join t2 a on (a.f1 = 1 and a.f1 = t1.f1 and a.f2 = t1.f2)
dtr-> where t1.f1 = 1 and a.f4 = 'xxx';
f1 | f2
+
1 | 20
(1 row)
dtr=> select t1.* from t1
dtr-> left join t2 a on (a.f1 = 1 and a.f1 = t1.f1 and a.f2 = t1.f2)
dtr-> left join t2 b on (b.f1 = 1 and b.f1 = t1.f1 and b.f2 = t1.f2 and b.f1
= 2)
dtr-> where t1.f1 = 1 and a.f4 = 'xxx';
f1 | f2
+
(0 rows)
dtr=> explain analyze
dtr-> select t1.* from t1
dtr-> left join t2 a on (a.f1 = 1 and a.f1 = t1.f1 and a.f2 = t1.f2)
dtr-> left join t2 b on (b.f1 = 1 and b.f1 = t1.f1 and b.f2 = t1.f2 and b.f1
= 2)
dtr-> where t1.f1 = 1 and a.f4 = 'xxx';
QUERY PLAN
--
Nested Loop Left Join (cost=0.00..11.79 rows=1 width=4) (actual
time=0.015..0.015 rows=0 loops=1)
Join Filter: (("inner".f2 = "outer".f2) AND ("inner".f1 = "outer".f1))
-> Nested Loop (cost=0.00..7.86 rows=1 width=4) (actual
time=0.014..0.014 rows=0 loops=1)
Join Filter: ("outer".f2 = "inner".f2)
-> Index Scan using t2_pkey on t2 a (cost=0.00..3.92 rows=1
width=4) (actual time=0.013..0.013 rows=0 loops=1)
Index Cond: ((f1 = 1) AND (2 = f1))
Filter: ((f4)::text = 'xxx'::text)
-> Index Scan using t1_pkey on t1 (cost=0.00..3.92 rows=1
width=4) (never executed)
Index Cond: ((f1 = 1) AND (2 = f1))
-> Index Scan using t2_pkey on t2 b (cost=0.00..3.92 rows=1 width=4)
(never executed)
Index Cond: ((f1 = 1) AND (f1 = 2))
Total runtime: 0.099 ms
(12 rows)
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1916: selection criteria from one outer join on clause applied to other joins
"Kevin Grittner" <[EMAIL PROTECTED]> writes: > Obviously, adding an outer join to a query which is already returning rows > should never reduce the number of rows returned. I think this is a case of overenthusiastic propagation of implied equalities. Do you know offhand if it fails in 8.0.* or earlier branches? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1916: selection criteria from one outer join on clause applied to other joins
On Wed, 28 Sep 2005 00:34:37 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: > "Kevin Grittner" <[EMAIL PROTECTED]> writes: > > Obviously, adding an outer join to a query which is already returning rows > > should never reduce the number of rows returned. > > I think this is a case of overenthusiastic propagation of implied > equalities. Do you know offhand if it fails in 8.0.* or earlier > branches? fails on 7.4.7 (rh9) and 8.0.0 (win) for me. klint. +---+-+ : Klint Gore: "Non rhyming: : EMail : [EMAIL PROTECTED] : slang - the: : Snail : A.B.R.I.: possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---+-+ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] HELP
Vaccaro wrote: I never download your product i don't even know what it is. When i started my computer up i saw 2 new accounts created. User Accounts. The accounts names were postgres services. It was password protected and limited account. I am running on windows XP. I Did delete the accounts. I want to know what happened i want it fixed. And i never want this to happen again You probably installed a piece of software that required PostgreSQL. If something you installed stops working, you will know what it is. Either that or someone else installed it for you in order to work with it. PostgreSQL is a relational database manager. It stores data for other programs. It is not adware, spyware, or anything like that. You can read more about it at http://www.postgresql.org Best Wishes, Chris Travers Metatron Technology Consulting [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
