[BUGS] BUG #3954: Duplicate Primary Keys
The following bug has been logged online: Bug reference: 3954 Logged by: Tapin Agarwal Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: Suse Description:Duplicate Primary Keys Details: Hi, We are using postgres-8.1.2 and observed the degradation in postgres performance. Select query was taking very long time to complete. While on a freshly installed postgres, with same number of records select query was getting completed within seconds. Our tables has indexes created on them and were running auto vacuum. Also we are not using any table inheritance. When tried to perform re-indexing, found that there were duplicate primary key entries in few of the tables. This problem has occurred several times on our database setup and every time different set of tables get affected. Can you please let us know if this issue is already resolved in any of the postgres releases. If it is then please let us know the release number. Regards, Tapin Agarwal ---(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 #3953: No PostGIS option in installer
The following bug has been logged online: Bug reference: 3953 Logged by: Rob von Nesselrode Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: WIndows XP Description:No PostGIS option in installer Details: That it! No PostGIS option in installer Doco for install is still 8.1 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3953: No PostGIS option in installer
On Feb 11, 2008 10:22 PM, Rob von Nesselrode <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 3953 > Logged by: Rob von Nesselrode > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3 > Operating system: WIndows XP > Description:No PostGIS option in installer > Details: > > That it! No PostGIS option in installer No. You can use Stackbuilder to install it now - it's installed by default with 8.3. > Doco for install is still 8.1 Not as far as I can see. Are you sure you're not looking at an old URL or shortcut? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company ---(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 #3957: make: *** [all] Error 2 / libpq.so.5.1
The following bug has been logged online:
Bug reference: 3957
Logged by: Vladimir Zuvela
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Red Hat Linux release 7.2 (Enigma) 2.4.7-10smp
Description:make: *** [all] Error 2 / libpq.so.5.1
Details:
when I try to execute the "make all" command I am getting an error
rm -f noblock.c && ln -s ../../../src/port/noblock.c .
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -fpic -DFRONTEND -I. -I../../../src/include
-D_GNU_SOURCE -I../../../src/port -c -o noblock.o noblock.c
rm -f pgstrcasecmp.c && ln -s ../../../src/port/pgstrcasecmp.c .
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -fpic -DFRONTEND -I. -I../../../src/include
-D_GNU_SOURCE -I../../../src/port -c -o pgstrcasecmp.o pgstrcasecmp.c
rm -f thread.c && ln -s ../../../src/port/thread.c .
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -fpic -DFRONTEND -I. -I../../../src/include
-D_GNU_SOURCE -I../../../src/port -c -o thread.o thread.c
rm -f strlcpy.c && ln -s ../../../src/port/strlcpy.c .
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -fpic -DFRONTEND -I. -I../../../src/include
-D_GNU_SOURCE -I../../../src/port -c -o strlcpy.o strlcpy.c
ar crs libpq.a fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o
fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o
md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o strlcpy.o
ranlib libpq.a
echo '{ global:' >exports.list
gawk '/^[^#]/ {printf "%s;\n",$1}' exports.txt >>exports.list
echo ' local: *; };' >>exports.list
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -fpic -shared -Wl,-soname,libpq.so.5
-Wl,--version-script=exports.list fe-auth.o fe-connect.o fe-exec.o
fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o
pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o
pgstrcasecmp.o thread.o strlcpy.o -L../../../src/port -lcrypt
-Wl,-rpath,'/sys2/postgres/release/8.3.0/lib' -o libpq.so.5.1
/usr/bin/ld:exports.list:1: parse error in VERSION script
collect2: ld returned 1 exit status
make[3]: *** [libpq.so.5.1] Error 1
make[3]: Leaving directory
`/z/vzuvela/postgresql-8.3.0/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/z/vzuvela/postgresql-8.3.0/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/z/vzuvela/postgresql-8.3.0/src'
make: *** [all] Error 2
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3957: make: *** [all] Error 2 / libpq.so.5.1
Vladimir Zuvela wrote: > PostgreSQL version: 8.0.3 > Operating system: Red Hat Linux release 7.2 (Enigma) 2.4.7-10smp > Description:make: *** [all] Error 2 / libpq.so.5.1 > > when I try to execute the "make all" command I am getting an error > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline > -fno-strict-aliasing -fpic -shared -Wl,-soname,libpq.so.5 > -Wl,--version-script=exports.list fe-auth.o fe-connect.o fe-exec.o > fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o > pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o > pgstrcasecmp.o thread.o strlcpy.o -L../../../src/port -lcrypt > -Wl,-rpath,'/sys2/postgres/release/8.3.0/lib' -o libpq.so.5.1 > > /usr/bin/ld:exports.list:1: parse error in VERSION script Right. We don't support so old a version of Linux. It has been said that you can make it work by hacking the Makefile to remove the --version-script stuff. However I question the usage of RH 7.2 which is several years without support. Also, 8.0.3 is not a good idea -- perhaps you want 8.0.15, or even a newer series, like 8.2.6. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3956: COPY FROM doesn't parse file correctly
"Maxim Ivanov" <[EMAIL PROTECTED]> writes: > COPY FROM couldn't parse file correctly. "\" symbol escapes delimeter. So > string(spaces are tabulation symbols) > 1 AA B\ CC > would be recognized as three field string instead of 4 field. Sounds perfectly correct to me. What were you expecting? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3956: COPY FROM doesn't parse file correctly
The following bug has been logged online: Bug reference: 3956 Logged by: Maxim Ivanov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Fedora i386 Description:COPY FROM doesn't parse file correctly Details: COPY FROM couldn't parse file correctly. "\" symbol escapes delimeter. So string(spaces are tabulation symbols) 1 AA B\ CC would be recognized as three field string instead of 4 field. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name
Kris, thanks for the advice. Because this rules out certain important features of the JPA framework such as native SQL queries, you may want to prioritize this issue. I will have to use Oracle or mySQL until PostgreSQL can rectify things. Thanks and regards Adam Kris Jurka on 01/02/08 20:45, wrote: On Fri, 1 Feb 2008, Adam Hardy wrote: it seems to me from what you just said that PostgreSQL server and JDBC driver require the schema name to be lower case deliberately, and that any given name that is not all lower case is converted to lower case by the server or the driver. Am I correct? Anything that is not quoted is converted to lowercase. This is contrary to the SQL spec (it says to convert it to uppercase), but that's unlikely to change anytime soon. A JDBC app can portably detect this case by checking DatabaseMetaData.storesLowerCaseIdentifiers() and adjusting the other metadata calls appropriately. Kris Jurka ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name
On Tue, 12 Feb 2008, Adam Hardy wrote: Because this rules out certain important features of the JPA framework such as native SQL queries, you may want to prioritize this issue. I will have to use Oracle or mySQL until PostgreSQL can rectify things. I wouldn't expect postgresql to change anytime soon. Could you explain in more detail what you can't use and why the JPA side couldn't be fixed to support postgresql? You could also consider always quoting all identifiers in both database creation scripts and queries. This guarantees that the database won't mess with the case of the object although it can be a pain to type if you writing a lot of queries by hand. Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3954: Duplicate Primary Keys
[Sorry I think I may have sent this out already with a typo in the version numbers. I may have cancelled in time but I'm not sure. This one is corrected] "Tapin Agarwal" <[EMAIL PROTECTED]> writes: > The following bug has been logged online: > > Bug reference: 3954 > Logged by: Tapin Agarwal > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.2 > Operating system: Suse > Description:Duplicate Primary Keys > Details: > > Hi, > > We are using postgres-8.1.2 and observed the degradation in postgres > performance. Select query was taking very long time to complete. While on a > freshly installed postgres, with same number of records select query was > getting completed within seconds. The most likely reason was having lots of dead tuples in the table due to vacuum not being run frequently enough. autovacuum has been improved dramatically in both 8.2 and 8.3 which would help avoid the need for additional manual vacuums. > Our tables has indexes created on them and were running auto vacuum. Also we > are not using any table inheritance. When tried to perform re-indexing, > found that there were duplicate primary key entries in few of the tables. > This problem has occurred several times on our database setup and every time > different set of tables get affected. > > Can you please let us know if this issue is already resolved in any of the > postgres releases. If it is then please let us know the release number. It does sound familiar though I don't find a specific changelog entry which describes that symptom. The version you're on is over 2 years old and there have been 9 subsequent bug-fix and security releases for that version. I would suggest you try to go to 8.1.11 immediately and plan to upgrade to 8.2 or 8.3 when possible to help with your vacuuming problems. Generally 8.1.11 is compatible with 8.1.x without a dump/restore or any semantic changes. However there were a couple gotchas in some of the intervening releases. Notably if you have any invalid UTF8 data in a UTF8-encoded database 8.1.11 will refuse to load it as it can be a security issue. The release notes for the 8.1.x bug-fix and security releases are at: http://www.postgresql.org/docs/8.1/static/release.html#RELEASE-8-1-11 Click "Next" or scroll up to the list to get the previous releases. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3954: Duplicate Primary Keys
"Tapin Agarwal" <[EMAIL PROTECTED]> writes: > The following bug has been logged online: > > Bug reference: 3954 > Logged by: Tapin Agarwal > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.2 > Operating system: Suse > Description:Duplicate Primary Keys > Details: > > Hi, > > We are using postgres-8.1.2 and observed the degradation in postgres > performance. Select query was taking very long time to complete. While on a > freshly installed postgres, with same number of records select query was > getting completed within seconds. The most likely reason was having lots of dead tuples in the table due to vacuum not being run frequently enough. autovacuum has been improved dramatically in both 8.2 and 8.3 which would help avoid the need for additional manual vacuums. > Our tables has indexes created on them and were running auto vacuum. Also we > are not using any table inheritance. When tried to perform re-indexing, > found that there were duplicate primary key entries in few of the tables. > This problem has occurred several times on our database setup and every time > different set of tables get affected. > > Can you please let us know if this issue is already resolved in any of the > postgres releases. If it is then please let us know the release number. It does sound familiar though I don't find a specific changelog entry which describes that symptom. The version you're on is over 2 years old and there have been 9 subsequent bug-fix and security releases for that version. I would suggest you try to go to 8.2.11 immediately and plan to upgrade to 8.2 or 8.3 when possible to help with your vacuuming problems. Generally 8.1.11 is compatible with 8.1.x without a dump/restore or any semantic changes. However there were a couple gotchas in some of the intervening releases. Notably if you have any invalid UTF8 data in a UTF8-encoded database 8.1.11 will refuse to load it as it can be a security issue. The release notes for the 8.1.x bug-fix and security releases are at: http://www.postgresql.org/docs/8.1/static/release.html#RELEASE-8-1-11 Click "Next" or scroll up to the list to get the previous releases. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
