[BUGS] BUG #1823: ODBC buffer overflow ?
The following bug has been logged online: Bug reference: 1823 Logged by: Marcello Semboli Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Win XP Description:ODBC buffer overflow ? Details: Hi, I administer a Windows application that write some information in a .ini file. Usually the application write the odbc driver that is using like this: [DB2_07.01.0002] RETRYCOUNT=20 RETRYWAITTIME=500 ... Wher I use odbc postgres driver I get following: [PostgreSQL_08.00.0100 PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (min RETRYCOUNT=20 [PostgreSQL_08.00.0100 PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (min RETRYWAITTIME=500 [PostgreSQL_08.00.0100 PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (min RETRYCOUNT=20 [PostgreSQL_08.00.0100 PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (min RETRYWAITTIME=500 [PostgreSQL_08.00.0100 PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (min RETRYCOUNT=20 [PostgreSQL_08.00.0100 PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (min RETRYWAITTIME=500 It seems like the driver string overruns. Bye. ---(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 #1800: "unexpected chunk number" during pg_dump
> Alvaro Herrera <[EMAIL PROTECTED]> 08/11/05 9:52 AM >>> > Anyway I was originally thinking the problem data was 4294879152 > (0xFFFEA7B0), not the 0. Have you tried to manually extract the data > from the dataset_cache table? You could try figuring out what page > contains the bad data, and manually peek into it using pg_filedump. Unfortunately, the table doesn't show any problems now (I truncated it after the pg_dump failed)and so there's not a lot of further detail I can give you. I suppose this means that we'll have to wait until such time as the problem shows up again before we can continue. Thanks for your help. -- Aaron Harsh [EMAIL PROTECTED] 503-284-7581 x347 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #1820: Installation: Dependency failure
The following bug has been logged online: Bug reference: 1820 Logged by: Bernard Email address: [EMAIL PROTECTED] PostgreSQL version: 8.03-1 Operating system: Linux RedHat 9 Description:Installation: Dependency failure Details: How to reproduce: - Install Red Hat 9 - Download all files from ftp://ftp.nz.postgresql.org/postgresql/binary/v8.0.3/linux/rpms/redhat/redha t-9/ into a single directory - execute # rpm -ivh * Expected behavior: The Postgresql core system should be installed Actual behavior: error: Failed dependencies: libecpg.so.4 is needed by postgresql-libs-8.0.3-1PGDG libpgtypes.so.1 is needed by postgresql-libs-8.0.3-1PGDG libpq.so.3 is needed by postgresql-libs-8.0.3-1PGDG There are other errors with non-core packages e.g postgresql-contrib but these are not subject of this bug. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1821: Source RPM: Missing dependency ncurses-devel
The following bug has been logged online: Bug reference: 1821 Logged by: Bernard Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3-1 Operating system: RedHat Linux 9 Description:Source RPM: Missing dependency ncurses-devel Details: How to reproduce: - Install RedHat 9 without any development packages - Install rpmbuild - Install postgresql/binary/v8.0.3/linux/srpms/redhat/redhat-9/postgresql-8.0.3-1PGDG. src.rpm - Install all packages that it requires in the order listed n th elist of failed dependencies - Build it Expected behavior: rpmbuild should succeed because all dependencies are satisfied. Actual behavior: rpmbuild fails as follows: configure: error: readline library not found If you have readline already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable readline support. error: Bad exit status from /home/builduser/rpm/tmp/rpm-tmp.42293 (%build) My workaround: I installed ncurses-devel-5.3-4.i386.rpm from the Redhat CD. Fixed the error but another error followed that is subject of another bug report. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1824: Error '?' on vizualition data
The following bug has been logged online: Bug reference: 1824 Logged by: Everton Johnny Email address: [EMAIL PROTECTED] PostgreSQL version: 7 e 8 Operating system: Windows 2000 Description:Error '?' on vizualition data Details: Hi, I have two problems the version difirents the PostgreSQL ODBC drivers: In driver ODBC version 7: The connection use ODBC driver return message 'blanck' and not conected. In driver ODBC version 8: Error '?' on vizualition data. My PostgreSQL 8.3 Linux installed e connection Delphi use ADO components. Please, my english is not good. Tanks, Everton Johnny ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1822: header file
The following bug has been logged online: Bug reference: 1822 Logged by: Bernard Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3-1 Operating system: RedHat Linux 9 Description:header file Details: How to reproduce: - Install RedHat 9 without any development packages - Install rpmbuild - Install postgresql/binary/v8.0.3/linux/srpms/redhat/redhat-9/postgresql-8.0.3-1PGDG. src.rpm - Install all packages that it requires in the order listed in the list of failed dependencies - Build it Expected behavior: rpmbuild should succeed because all dependencies are satisfied. Actual behavior: rpmbuild fails as follows: configure: error: header file is required for Kerberos 5 error: Bad exit status from /home/builduser/rpm/tmp/rpm-tmp.62787 (%build) RPM build errors: Bad exit status from /home/builduser/rpm/tmp/rpm-tmp.62787 (%build) ## I don't have any workaround for this. krb5.h is in /usr/kerberos/include/krb5.h ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1819: COPY filename rejects Windows format path
At 09:47 AM 8/11/2005, Richard Huxton wrote: Steve Peterson wrote: Running COPY FROM on a Windows server; using a Windows-format fully qualified path with backslashes results in the backslashes being interpreted as escapes. Did you escape the backslashes: C:\\Windows\\Path ? Nope. I used a standard Windows path, copied from the address field in Windows explorer. I see now on http://www.postgresql.org/docs/8.0/interactive/sql-syntax.html#SQL-SYNTAX-CONSTANTS (I know, RTFM) that it's documented that the SQL string literal is extended to accept backslash as an escape, so this is a documented behavior. Can I convert this bug into a docs bug -- to mention the escaping process wherever a filename is specified in a SQL string constant? S ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] [8.0.0] out of memory on large UPDATE
On Thu, 11 Aug 2005, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: On Thu, 11 Aug 2005, Tom Lane wrote: Are you *sure* there are no AFTER triggers here? (Don't forget foreign-key checking triggers.) This is all of them ... nothing AFTER, just ON or BEFORE ... Foreign-key constraints: "xa_classification_id_fk" FOREIGN KEY (classification_id) REFERENCES xa_classification(classification_id) ON UPDATE RESTRICT ON DELETE RESTRICT "xa_ip_address_id_fk" FOREIGN KEY (ip_address_id) REFERENCES xa_ip_addresses(ip_address_id) ON UPDATE RESTRICT ON DELETE RESTRICT "xa_logger_status_id_fk" FOREIGN KEY (logger_status_id) REFERENCES xa_logger_status(logger_status_id) ON UPDATE RESTRICT ON DELETE RESTRICT "xa_url_queue_id_fk" FOREIGN KEY (url_queue_id) REFERENCES xa_url_queue(url_queue_id) ON UPDATE RESTRICT ON DELETE SET NULL Triggers: xa_url_domain_b_i_u BEFORE INSERT OR UPDATE ON xa_url FOR EACH ROW EXECUTE PROCEDURE xa_url_domain() Um, foreign-key triggers are always AFTER. Ah, k ... that would actually make sense had I thought of it too :( Can you afford to drop the FK constraints while you do the update? I can't think of any other short-term workaround. Not sure, but is there a way to do so temporarily? DarcyB and I were talking the other day about how slow things where for that UPDATE ... I figured alot of the cause was the UPDATEng of the INDICES at the same time, so he suggested doing something they are apparenty looking for with Slony, and "temporarily disabling" the indices inside a transaction, and then REINDEXng at the end ... ie. BEGIN; UPDATE pg_catalog.pg_class SET relhasindex = 'f' WHERE pg_catalog.pg_class.oid= 'tableoid'; UPDATE pg_catalog.pg_class SET relhasindex = 't' WHERE pg_catalog.pg_class.oid= 'tableoid'; REINDEX; END; Could I do similar setting "relfkeys = 'f'"? Or is it more complicated then that? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1766: contrib/ modules can't install with --without-docdir
Patch applied. Thanks. --- ISHIDA Akio wrote: > > The following bug has been logged online: > > Bug reference: 1766 > Logged by: ISHIDA Akio > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: Linux > Description:contrib/ modules can't install with --without-docdir > Details: > > $ ./configure --without-docdir > .. > $ cd contrib/pgstattuple/ > $ make install > mkdir -p -- /contrib > mkdir: cannot create directory `/contrib': Permission denied > make: *** [installdirs] Error 1 > > > --- src/makefiles/pgxs.mk.org 2004-10-11 01:13:03.0 +0900 > +++ src/makefiles/pgxs.mk 2005-07-14 09:54:24.0 +0900 > @@ -100,10 +100,12 @@ > done > endif # MODULES > ifdef DOCS > +ifdef docdir > @for file in $(addprefix $(srcdir)/, $(DOCS)); do \ > echo "$(INSTALL_DATA) $$file $(DESTDIR)$(docdir)/contrib"; \ > $(INSTALL_DATA) $$file $(DESTDIR)$(docdir)/contrib; \ > done > +endif # docdir > endif # DOCS > ifdef PROGRAM > $(INSTALL_PROGRAM) $(PROGRAM)$(X) $(DESTDIR)$(bindir) > @@ -133,8 +135,10 @@ > $(mkinstalldirs) $(DESTDIR)$(pkglibdir) > endif > ifdef DOCS > +ifdef docdir > $(mkinstalldirs) $(DESTDIR)$(docdir)/contrib > -endif > +endif # docdir > +endif # DOCS > ifneq (,$(PROGRAM)$(SCRIPTS)$(SCRIPTS_built)) > $(mkinstalldirs) $(DESTDIR)$(bindir) > endif > > ---(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 > -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [BUGS] BUG #1794: inheritance removes permissions from
Patch applied. Thanks. --- Sean Burlington wrote: > Michael Fuhr wrote: > > On Thu, Jul 28, 2005 at 03:56:14PM +0100, Sean Burlington wrote: > > > >>Michael Fuhr wrote: > >> > >>>On Thu, Jul 28, 2005 at 12:48:35PM +0100, Sean Burlington wrote: > >>> > >>> > Description:inheritance removes permissions from the parent table > >>> > >>>I think a more accurate description would be "permissions not > >>>inherited by children," and that isn't necessarily a bug. > >> > >>I agree it may not be a bug - but it's more than the permissions not > >>being inherited: the parent is affected. > > > > > > Not really, once you understand what's happening. Unless you use > > FROM ONLY, selecting from the parent selects from the parent *and* > > its children. The parent itself isn't affected, as queries with > > FROM ONLY should demonstrate. I understand what you're saying -- > > that there's an apparent effect on the parent -- but there really > > isn't. > > > > > >>It would be handy if this was in the documentation for anyone else who > >>comes across this issue > > > > > > Feel free to submit a documentation patch to pgsql-patches :-) > > > > OK - patch attached > > I hope it's OK - I'm afraid I didn't spend too much time looking at the > best way to contribute patches and just went ahead and made one ... > > -- > > Sean > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- 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
Re: [BUGS] Server broken down in covering GB18030
Has this been fixed already? --- Qingqing Zhou wrote: > > My theory is "select;" incurs a parse error and this error message is > supposed to be translated into your encoding, but unfortunately not every > UTF8 character is necessarily be encoded as GB18030, which will cause an > infinite recursive elogs just like this: > > 1:elog(parse_error)// contain unencodable characters > 2:elog(report_not_translatable)// contain unencodable characters > again > 3:elog(report_report_not_translatable) > 4:elog(report_report_report_not_translatable) > 5:... > > and corrupt the elog stack. > > To fix this, we could just print a "Unsupport encoding" message which is > just a plain ascii character string and stop the recursion at step 3. > > Regards, > Qingqing > > "" <[EMAIL PROTECTED]> writes > > template1=# select version(); > > PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) > > 3.4.2 (mingw-special) > > template1=# create database test1 encoding 'unicode'; > > test1=# \encoding > > UNICODE > > test1=# \encoding gb18030 > > test1=# \encoding > > GB18030 > > test1=# select; > ... > > ??: ERRORDATA_STACK_SIZE exceeded > > > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > -- 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 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
