[BUGS]
Hi,
I sent this message to [EMAIL PROTECTED] a couple of weeks ago and I
got an automated response from [EMAIL PROTECTED] indicating that I'd
been subscribed to this list, but I've not seen any traffic from it all since
then. Either there are really very few bugs in PostgreSQL (congratulations!)
or something is wrong with my subscription. Any (non-automatic) feedback
would be welcomed.
Here's the message again:
I'm using V 7.0 on a Linux machine and I believe I have found a bug in the
large object interface provided by libpq. The code below will reproduce it, I
hope. Basically it creates a large object, writes six 'a' characters to it,
then closes it. Then, in another transaction, it opens the object, seeks to
position 1 from the start, writes a 'b', then seeks to position 3 from the
start and writes another 'b'. Then it closes the object and COMMITs the
transaction. Finally, in a further separate transaction, it calls lo_export
to write out the resulting object to a file testloseek.c.lobj I find this
file, instead of containing the string 'ababaa' as expected, contains
'^@b^@baa' where ^@ is ASCII NUL.
Compile with something like
gcc -o testloseek testloseek.c -lpq
The program sets the PQtrace to STDOUT and writes messages to STDERR, so run
it with STDOUT redirected to a log file.
This is a C version of a basic regression test of guile-pg, my Guile language
bindings for libpq. You may recall I reported a similar bug a year or so ago,
and I believed it was then fixed by Tatsuo, after a couple of iterations. I'm
sorry to be the bearer of bad news ...
Please reply to me directly since I'm not on the list.
Thanks
Ian
#include
#include "libpq-fe.h"
#include "libpq/libpq-fs.h"
void exec_cmd(PGconn *conn, char *str);
main (int argc, char *argv[])
{
PGconn *conn;
int lobj_fd;
char buf[256];
int ret, i;
Oid lobj_id;
conn = PQconnectdb("dbname=test");
if (PQstatus(conn) != CONNECTION_OK) {
fprintf(stderr, "Can't connect to backend.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
exec_cmd(conn, "BEGIN TRANSACTION");
PQtrace (conn, stdout);
if ((lobj_id = lo_creat(conn, INV_READ | INV_WRITE)) < 0) {
fprintf(stderr, "Can't create lobj.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
fprintf(stderr, "lo_creat() returned OID %ld.\n", lobj_id);
if ((lobj_fd = lo_open(conn, lobj_id, INV_READ | INV_WRITE)) < 0) {
fprintf(stderr, "Can't open lobj.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
fprintf(stderr, "lo_open returned fd = %d.\n", lobj_fd);
if ((ret = lo_write(conn, lobj_fd, "aa", 6)) != 6) {
fprintf(stderr, "Can't write lobj.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
ret = lo_close(conn, lobj_fd);
printf("lo_close returned %d.\n", ret);
exec_cmd(conn, "END TRANSACTION");
exec_cmd(conn, "BEGIN TRANSACTION");
if ((lobj_fd = lo_open(conn, lobj_id, INV_READ | INV_WRITE)) < 0) {
fprintf(stderr, "Can't open lobj.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
fprintf(stderr, "lo_open returned fd = %d.\n", lobj_fd);
if (ret)
fprintf(stderr, "Error message: %s\n", PQerrorMessage(conn));
if ((ret = lo_lseek(conn, lobj_fd, 1, 0)) != 1) {
fprintf(stderr, "error (%d) lseeking in large object.\n", ret);
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
if ((ret = lo_write(conn, lobj_fd, "b", 1)) != 1) {
fprintf(stderr, "Can't write lobj.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
if ((ret = lo_lseek(conn, lobj_fd, 3, 0)) != 3) {
fprintf(stderr, "error (%d) lseeking in large object.\n", ret);
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
if ((ret = lo_write(conn, lobj_fd, "b", 1)) != 1) {
fprintf(stderr, "Can't write lobj.\n");
fprintf(stderr, "ERROR: %s\n", PQerrorMessage(conn));
exit(1);
}
ret = lo_close(conn, lobj_fd);
printf("lo_close returned %d.\n", ret);
if (ret)
fprintf(stderr, "Error message: %s\n", PQerrorMessage(conn));
PQuntrace(conn);
exec_cmd(conn, "END TRANSACTION");
exec_cmd(conn, "BEGIN TRANSACTION");
ret = lo_export(conn, lobj_id, "testloseek.c.lobj");
printf("lo_export returned %d.\n", ret);
if (ret != 1)
fprintf(stderr, "Error message: %s\n", PQerrorMessage(conn));
exec_cmd(conn, "END TRANSACTION");
exit(0);
}
void exec_cmd(PGconn *conn, char *str)
{
PGresult *res;
if ((res = PQexec(conn, str)) == NULL) {
fprintf(stderr, "Error executing %s.\n", str);
fprintf(stderr, "Error message: %s\n", PQerrorMessage(conn));
exit(1);
}
if (PQresultStatus(res) != PGRES_COMMAND_OK) {
fprintf(stderr, "Error executing %s.\n", str);
fprintf(std
Re: [BUGS] libpgtcl
I am happy to back it out. Comments? [Let me give the author time to respond.] [ Charset ISO-8859-1 unsupported, converting... ] > I just looked at this yesterday and I wonder why one would want to do > this. The libpgtcl build works perfectly fine and it doesn't even link > with tcl, so there's little reason to "integrate the tcl-spec" into > things. The only thing that this change accomplishes is that it makes the > libpgtcl build deviate more from the common behaviour (for example by not > using the compiler the user specified). IMHO, the custom build code for > the Perl, Python, and part of the Tcl interface should be considered a > necessary evil since we don't know better but nothing that should be > propagated unnecessarily. > > > On Tue, 13 Jun 2000, Bruce Momjian wrote: > > > Applied. > > > > > > > Hello, > > > > > > in the Directory src/bin/pgtclsh there is a good mechanism to integrate > > > the > > > tcl-spec in the Makefile. > > > The patch in the attachemant does this in the src/interfaces/libpgtcl > > > too > > > > > > Thank you > > > Rudolf > > > -- > > > --- > > > Rudolf Weber > > > http://www.infnet.verein.de/home/rw > > > E-Mail: [EMAIL PROTECTED] > > > > > --- ./src/interfaces/libpgtcl/mkMakefile.tcldefs.sh.in.orig Tue Jun 6 >01:03:10 2000 > > > +++ ./src/interfaces/libpgtcl/mkMakefile.tcldefs.sh.inTue Jun 6 01:02:19 >2000 > > > @@ -0,0 +1,16 @@ > > > + > > > +if [ ! -f @TCL_CONFIG_SH@ ]; then > > > +echo "@TCL_CONFIG_SH@ not found" > > > +echo "I need this file! Please make a symbolic link to this file" > > > +echo "and start make again." > > > +exit 1 > > > +fi > > > + > > > +cat @TCL_CONFIG_SH@ | > > > +egrep '^TCL_' | > > > +while read inp > > > +do > > > + eval eval echo $inp > > > +done >Makefile.tcldefs > > > + > > > +exit 0 > > > --- ./src/interfaces/libpgtcl/mkMakefile.tkdefs.sh.in.origTue Jun 6 >01:03:21 2000 > > > +++ ./src/interfaces/libpgtcl/mkMakefile.tkdefs.sh.in Tue Jun 6 01:02:19 >2000 > > > @@ -0,0 +1,18 @@ > > > + > > > +if [ ! -f @TK_CONFIG_SH@ ]; then > > > +echo "@TK_CONFIG_SH@ not found" > > > +echo "I need this file! Please make a symbolic link to this file" > > > +echo "and start make again." > > > +exit 1 > > > +fi > > > + > > > +. @TK_CONFIG_SH@ > > > + > > > +cat @TK_CONFIG_SH@ | > > > +egrep '^TK_' | > > > +while read inp > > > +do > > > + eval eval echo $inp > > > +done >Makefile.tkdefs > > > + > > > +exit 0 > > > --- ./src/interfaces/libpgtcl/Makefile.in.origWed Mar 8 02:58:36 2000 > > > +++ ./src/interfaces/libpgtcl/Makefile.in Tue Jun 6 01:22:46 2000 > > > @@ -17,6 +17,14 @@ > > > SRCDIR= @top_srcdir@ > > > include $(SRCDIR)/Makefile.global > > > > > > +# > > > +# Include definitions from the tclConfig.sh file > > > +# > > > +include Makefile.tcldefs > > > +ifeq ($(USE_TK), true) > > > +include Makefile.tkdefs > > > +endif > > > + > > > CFLAGS+= -I$(SRCDIR)/backend \ > > > -I$(SRCDIR)/include \ > > > -I$(LIBPQDIR) > > > @@ -48,6 +56,11 @@ > > > beforeinstall-headers: > > > -@if [ ! -d $(HEADERDIR) ]; then mkdir $(HEADERDIR); fi > > > > > > +Makefile.tcldefs: mkMakefile.tcldefs.sh > > > + /bin/sh mkMakefile.tcldefs.sh > > > + > > > +Makefile.tkdefs: mkMakefile.tkdefs.sh > > > + /bin/sh mkMakefile.tkdefs.sh > > > > > > .PHONY: clean > > > > > > --- ./src/configure.in.orig Thu May 25 00:43:59 2000 > > > +++ ./src/configure.inTue Jun 6 01:16:10 2000 > > > @@ -1371,6 +1371,8 @@ > > > interfaces/ecpg/preproc/Makefile > > > interfaces/libpq++/Makefile > > > interfaces/libpgeasy/Makefile > > > + interfaces/libpgtcl/mkMakefile.tcldefs.sh > > > + interfaces/libpgtcl/mkMakefile.tkdefs.sh > > > interfaces/libpgtcl/Makefile > > > interfaces/odbc/GNUmakefile > > > interfaces/odbc/Makefile.global > > > > > > > > -- > Peter Eisentraut Sernanders v?g 10:115 > [EMAIL PROTECTED] 75262 Uppsala > http://yi.org/peter-e/Sweden > > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Where is a compile bug in postgresql-7.0beta2 reported?
Added to TODO list: * BSD/OS does not support locale because there is no LC_MESSAGES I have contacted BSDI support about the problem. [ Charset ISO-8859-1 unsupported, converting... ] > Do we know anybody with BSDI 4.1? LC_MESSAGES may have made it into that > release, though I have no way of checking this since my support contract has > expired :-(. I'll renew, but that doesn't help for an April release. > > Regards, > - Steve > > - Original Message - > From: Tom Lane <[EMAIL PROTECTED]> > To: Bruce Momjian <[EMAIL PROTECTED]> > Cc: Steve Nunez <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Monday, March 20, 2000 12:36 PM > Subject: Re: [BUGS] Where is a compile bug in postgresql-7.0beta2 reported? > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Yes, I see it here on BSD/OS 4.01 with --enable_locale. It is from: > > > > > lc->lc_messages = setlocale(LC_MESSAGES, NULL); > > > > > BSDI does not define LC_MESSAGES as part of its setlocale() interface. > > > Is this a standard feature that BSDI is missing, or some specific > > > extension? > > > > HPUX has LC_MESSAGES, and I don't usually find them to be out on the > > bleeding edge of conformance to new standards. The HPUX man page > > for setlocale() --- which specifically lists LC_MESSAGES --- says > > > > STANDARDS COMPLIANCE > > setlocale(): AES, SVID3, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C > > > > which are all pretty ancient. So I suspect BSDI is behind the curve. > > > > Next question is what to do about it. We could do #ifdef LC_MESSAGES, > > but what do we need to do if it's not defined? > > > > regards, tom lane > > > > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] libpgtcl
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am happy to back it out. Comments? [Let me give the author time to > respond.] >> I just looked at this yesterday and I wonder why one would want to do >> this. The libpgtcl build works perfectly fine and it doesn't even link >> with tcl, so there's little reason to "integrate the tcl-spec" into >> things. My thoughts were pretty much the same as Peter's. We use the Tcl compiler and switches for pltcl because it was the path of least resistance for linking in libtcl.so. But the libpgtcl interface doesn't do that, and has not been a source of portability problems --- and it's been around for a lot longer than pltcl (we don't really know that pltcl's scheme works for everyone). So changing the way we build libpgtcl seems to me to be a risky change for little or no benefit. My inclination is to sail along with the two different build approaches for a few releases and see what sort of portability problems we hear about. Perhaps in a year or so it'll make sense to unify the handling of libpgtcl and pltcl, but right now I'm dubious. regards, tom lane
Re: [BUGS] libpgtcl
I will back it out then. > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am happy to back it out. Comments? [Let me give the author time to > > respond.] > > >> I just looked at this yesterday and I wonder why one would want to do > >> this. The libpgtcl build works perfectly fine and it doesn't even link > >> with tcl, so there's little reason to "integrate the tcl-spec" into > >> things. > > My thoughts were pretty much the same as Peter's. We use the Tcl > compiler and switches for pltcl because it was the path of least > resistance for linking in libtcl.so. But the libpgtcl interface > doesn't do that, and has not been a source of portability problems > --- and it's been around for a lot longer than pltcl (we don't > really know that pltcl's scheme works for everyone). So changing > the way we build libpgtcl seems to me to be a risky change for > little or no benefit. > > My inclination is to sail along with the two different build > approaches for a few releases and see what sort of portability > problems we hear about. Perhaps in a year or so it'll make sense to > unify the handling of libpgtcl and pltcl, but right now I'm dubious. > > regards, tom lane > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] libpgtcl
Backed out. [ Charset ISO-8859-1 unsupported, converting... ] > I just looked at this yesterday and I wonder why one would want to do > this. The libpgtcl build works perfectly fine and it doesn't even link > with tcl, so there's little reason to "integrate the tcl-spec" into > things. The only thing that this change accomplishes is that it makes the > libpgtcl build deviate more from the common behaviour (for example by not > using the compiler the user specified). IMHO, the custom build code for > the Perl, Python, and part of the Tcl interface should be considered a > necessary evil since we don't know better but nothing that should be > propagated unnecessarily. > > > On Tue, 13 Jun 2000, Bruce Momjian wrote: > > > Applied. > > > > > > > Hello, > > > > > > in the Directory src/bin/pgtclsh there is a good mechanism to integrate > > > the > > > tcl-spec in the Makefile. > > > The patch in the attachemant does this in the src/interfaces/libpgtcl > > > too > > > > > > Thank you > > > Rudolf > > > -- > > > --- > > > Rudolf Weber > > > http://www.infnet.verein.de/home/rw > > > E-Mail: [EMAIL PROTECTED] > > > > > --- ./src/interfaces/libpgtcl/mkMakefile.tcldefs.sh.in.orig Tue Jun 6 >01:03:10 2000 > > > +++ ./src/interfaces/libpgtcl/mkMakefile.tcldefs.sh.inTue Jun 6 01:02:19 >2000 > > > @@ -0,0 +1,16 @@ > > > + > > > +if [ ! -f @TCL_CONFIG_SH@ ]; then > > > +echo "@TCL_CONFIG_SH@ not found" > > > +echo "I need this file! Please make a symbolic link to this file" > > > +echo "and start make again." > > > +exit 1 > > > +fi > > > + > > > +cat @TCL_CONFIG_SH@ | > > > +egrep '^TCL_' | > > > +while read inp > > > +do > > > + eval eval echo $inp > > > +done >Makefile.tcldefs > > > + > > > +exit 0 > > > --- ./src/interfaces/libpgtcl/mkMakefile.tkdefs.sh.in.origTue Jun 6 >01:03:21 2000 > > > +++ ./src/interfaces/libpgtcl/mkMakefile.tkdefs.sh.in Tue Jun 6 01:02:19 >2000 > > > @@ -0,0 +1,18 @@ > > > + > > > +if [ ! -f @TK_CONFIG_SH@ ]; then > > > +echo "@TK_CONFIG_SH@ not found" > > > +echo "I need this file! Please make a symbolic link to this file" > > > +echo "and start make again." > > > +exit 1 > > > +fi > > > + > > > +. @TK_CONFIG_SH@ > > > + > > > +cat @TK_CONFIG_SH@ | > > > +egrep '^TK_' | > > > +while read inp > > > +do > > > + eval eval echo $inp > > > +done >Makefile.tkdefs > > > + > > > +exit 0 > > > --- ./src/interfaces/libpgtcl/Makefile.in.origWed Mar 8 02:58:36 2000 > > > +++ ./src/interfaces/libpgtcl/Makefile.in Tue Jun 6 01:22:46 2000 > > > @@ -17,6 +17,14 @@ > > > SRCDIR= @top_srcdir@ > > > include $(SRCDIR)/Makefile.global > > > > > > +# > > > +# Include definitions from the tclConfig.sh file > > > +# > > > +include Makefile.tcldefs > > > +ifeq ($(USE_TK), true) > > > +include Makefile.tkdefs > > > +endif > > > + > > > CFLAGS+= -I$(SRCDIR)/backend \ > > > -I$(SRCDIR)/include \ > > > -I$(LIBPQDIR) > > > @@ -48,6 +56,11 @@ > > > beforeinstall-headers: > > > -@if [ ! -d $(HEADERDIR) ]; then mkdir $(HEADERDIR); fi > > > > > > +Makefile.tcldefs: mkMakefile.tcldefs.sh > > > + /bin/sh mkMakefile.tcldefs.sh > > > + > > > +Makefile.tkdefs: mkMakefile.tkdefs.sh > > > + /bin/sh mkMakefile.tkdefs.sh > > > > > > .PHONY: clean > > > > > > --- ./src/configure.in.orig Thu May 25 00:43:59 2000 > > > +++ ./src/configure.inTue Jun 6 01:16:10 2000 > > > @@ -1371,6 +1371,8 @@ > > > interfaces/ecpg/preproc/Makefile > > > interfaces/libpq++/Makefile > > > interfaces/libpgeasy/Makefile > > > + interfaces/libpgtcl/mkMakefile.tcldefs.sh > > > + interfaces/libpgtcl/mkMakefile.tkdefs.sh > > > interfaces/libpgtcl/Makefile > > > interfaces/odbc/GNUmakefile > > > interfaces/odbc/Makefile.global > > > > > > > > -- > Peter Eisentraut Sernanders v?g 10:115 > [EMAIL PROTECTED] 75262 Uppsala > http://yi.org/peter-e/Sweden > > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[BUGS] info on unixODBC/Postgres driver port to IRIX 6.5.7 64bit
Hello, This is a report on my attempts to install unixODBC (1.8.9) and postgres odbc driver on IRIX 6.5.7 64bit using the native compiler. There are a number of changes that were necessary to be made on both the configuration files and source to get it to compile. patches are attached. some of these were derived from 1.8.8, but they all apply successfully on 1.8.9. UnixODBC 1- you can ignore the changes to acinclude.m4. they are a hack to augment the qt libraries for my platform. a more thoughtful allowance for this possibility though might be needed. 2- I had to propagate USER_LDFLAGS into DataManager/Makefile.in, ODBCConfig/Makefile.in and odbctest/Makefile.am adding it to LDADD flags. There is no reason not to and they were needed in my case to find all qt related libraries. 3- The IRIX native compiler does not like having new lines in strings. I had to delete spurious new lines from a few strings in DataManager/classLogin.cpp and DataManager/classISQL.cpp 4- default values for function arguments were defined twice in a number of files. in the headers as well as in cpp files. IRIX compiler does not like that besides it is a maintenance burden. I kept the default arguments in the header files only (see patch). 5- Needed to insert explicit type casts in some places as well as leading function prototypes (see patch). Postgres ODBC driver 6- One bug that was hard to track was related to the postgres driver. The driver defines #define Int4 long int; in psqlodbc.h. unfortunately, when compiling 64bit a long int is 8 bytes. for my setup I hacked it by changing that to #define Int4 int; which I think is probably appropriate on most platforms. But this type should really be determined at configure time. Regards -- Murad Nayal M.D. Ph.D. Department of Biochemistry and Molecular Biophysics College of Physicians and Surgeons of Columbia University 630 West 168th Street. New York, NY 10032 Tel: 212-305-6884 Fax: 212-305-6926 *** ./acinclude.m4.bk1 Wed Jun 14 13:30:52 2000 --- ./acinclude.m4 Wed Jun 14 00:47:35 2000 *** *** 562,568 fi AC_MSG_CHECKING([for Qt]) ! LIBQT="$LIBQT -lXext -lX11 $LIBSOCKET" ac_qt_includes=NO ac_qt_libraries=NO ac_qt_bindir=NO qt_libraries="" qt_includes="" --- 562,568 fi AC_MSG_CHECKING([for Qt]) ! LIBQT="$LIBQT -ljpeg -lSM -lICE -lXext -lX11 $LIBSOCKET" ac_qt_includes=NO ac_qt_libraries=NO ac_qt_bindir=NO qt_libraries="" qt_includes="" *** *** 693,699 AC_SUBST(QT_LDFLAGS) AC_PATH_QT_MOC ! LIB_QT='-lqt $(LIBPNG) -lXext $(LIB_X11)' AC_SUBST(LIB_QT) ]) --- 693,699 AC_SUBST(QT_LDFLAGS) AC_PATH_QT_MOC ! LIB_QT='-lqt $(LIBPNG) -ljpeg -lSM -lICE -lXext $(LIB_X11)' AC_SUBST(LIB_QT) ]) *** ./DataManager/Makefile.in.bk1 Wed Jun 14 13:28:47 2000 --- ./DataManager/Makefile.in Tue Jun 13 13:25:30 2000 *** *** 176,182 @QT_TRUE@INCLUDES = -I../include @QT_INCLUDES@ ! @QT_TRUE@DataManager_LDADD = @X_LDFLAGS@ @QT_LDFLAGS@@LIB_QT@ ../odbcinst/libodbcinst.la ../DriverManager/libodbc.la @QT_TRUE@DataManager_DEPENDANCIES = ../odbcinst/libodbcinst.la ../DriverManager/libodbc.la --- 176,182 @QT_TRUE@INCLUDES = -I../include @QT_INCLUDES@ ! @QT_TRUE@DataManager_LDADD = @X_LDFLAGS@ @QT_LDFLAGS@ @USER_LDFLAGS@ @LIB_QT@../odbcinst/libodbcinst.la ../DriverManager/libodbc.la @QT_TRUE@DataManager_DEPENDANCIES = ../odbcinst/libodbcinst.la ../DriverManager/libodbc.la *** ./ODBCConfig/Makefile.in.bk1Tue Jun 13 13:18:55 2000 --- ./ODBCConfig/Makefile.inTue Jun 13 13:25:00 2000 *** *** 176,182 @QT_TRUE@INCLUDES = -I../include @QT_INCLUDES@ -DSYSTEM_FILE_PATH=\"@sysconfdir@\" -DDEFLIB_PATH=\"@libdir@\" $(INCLTDL) ! @QT_TRUE@ODBCConfig_LDADD = @X_LDFLAGS@ @QT_LDFLAGS@@LIB_QT@ ../odbcinst/libodbcinst.la ../extras/libodbcextraslc.la @QT_TRUE@ODBCConfig_DEPENDANCIES = ../odbcinst/libodbcinst.la ../extras/libodbcextraslc.la --- 176,182 @QT_TRUE@INCLUDES = -I../include @QT_INCLUDES@ -DSYSTEM_FILE_PATH=\"@sysconfdir@\" -DDEFLIB_PATH=\"@libdir@\" $(INCLTDL) ! @QT_TRUE@ODBCConfig_LDADD = @X_LDFLAGS@ @QT_LDFLAGS@ @USER_LDFLAGS@ @LIB_QT@../odbcinst/libodbcinst.la ../extras/libodbcextraslc.la @QT_TRUE@ODBCConfig_DEPENDANCIES = ../odbcinst/libodbcinst.la ../extras/libodbcextraslc.la *** odbctest/Makefile.am.bk1Wed Jun 14 15:16:22 2000 --- odbctest/Makefile.amWed Jun 14 15:16:37 2000 *** *** 6,11 --- 6,12 odbctest_LDADD = @X_LDFLAGS@ \ @QT_LDFLAGS@ \ + @USER_LDFLAGS@ \ @LIB_QT@ \ ../odbcinst/libodbcinst.la \ ../DriverManager/libodbc.la *** ./DataManager/classLogin.cpp.bk1Tue Jun 13 14:20:07 2000 --- ./DataManager/classLogin.cppTue Jun 13 14:20:57 20
Re: [BUGS] jdbc2 bug in absolute (ResultSet.java)
I'm the one who posted this question and also posted the patch to fix it. Thanks for including it. The version of the JDBC driver in the cvs fixes all the problems I know of regarding indexing (I re-wrote absolute). Absolute and relative do not work properly in the 7.0 driver. Thanks, Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer On Tue, 13 Jun 2000, Bruce Momjian wrote: > > The "absolute" method is called by the relative method to change the > > cursor position. However, I noticed that absolute does not change > > current_row, it only loads the data. > > > > Shoudn't absolute contain the following line : > > > > current_row=index; > > > > The current code shows: > > current_row=internalIndex; > > Seems it has been fixed by someone. Yes, I see now that the 7.0.0 > version has this missing. > > Not sure how to handle this. The fix will be in 7.1. Just not sure if > I should back-patch this into 7.0.X because there are other fixes in > those java patches I don't understand. > > -- > Bruce Momjian| http://www.op.net/~candle > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 >
Re: [BUGS] jdbc2 bug in absolute (ResultSet.java)
Thanks. I will back-patch these in to 7.0.X. > I'm the one who posted this question and also posted the patch to fix it. > Thanks for including it. The version of the JDBC driver in the cvs fixes > all the problems I know of regarding indexing (I re-wrote > absolute). Absolute and relative do not work properly in the 7.0 driver. > > Thanks, > > > Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer > > > On Tue, 13 Jun 2000, Bruce Momjian wrote: > > > > The "absolute" method is called by the relative method to change the > > > cursor position. However, I noticed that absolute does not change > > > current_row, it only loads the data. > > > > > > Shoudn't absolute contain the following line : > > > > > > current_row=index; > > > > > > > The current code shows: > > > > current_row=internalIndex; > > > > Seems it has been fixed by someone. Yes, I see now that the 7.0.0 > > version has this missing. > > > > Not sure how to handle this. The fix will be in 7.1. Just not sure if > > I should back-patch this into 7.0.X because there are other fixes in > > those java patches I don't understand. > > > > -- > > Bruce Momjian| http://www.op.net/~candle > > [EMAIL PROTECTED] | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > > > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[BUGS] Some problem with inet type on PostgreSQL-7.0
Hi All, I have some problem with inet type on PostgreSQL-7.0 (FreeBSD 3.4-STABLE) Table "ipaddresses" Attribute | Type | Modifier --+-+ sysname | text| not null index| integer | not null ip_addr | inet| not null Indices: ipaddresses_ip_addr, ipaddresses_pkey (sysname, ip_addr) - PRIMARY KEY View "ipaddresses_view" Attribute | Type | Modifier --+-+-- sysname | text| index| integer | ip_addr | inet| ip_netmask | inet| View definition: SELECT ipaddresses.sysname, ipaddresses."index", ipv4_host(ipaddresses.ip_addr) AS ip_addr, ipv4_netmask(ipaddresses.ip_addr) AS ip_netmask FROM ipaddresses; ipv4_host and ipv4_netmask like original host and netmask but return inet type ( need for ORDER ) CREATE FUNCTION ipv4_host(inet) RETURNS inet AS ' BEGIN RETURN host($1); END; ' LANGUAGE 'plpgsql'; CREATE FUNCTION ipv4_netmask(inet) RETURNS inet AS ' BEGIN RETURN netmask($1); END; ' LANGUAGE 'plpgsql'; Problem select * from ipaddresses where sysname = 'switch01.tor'; sysname| index | ip_addr --+---+-- switch01.tor | 1 | 127.0/8 switch01.tor | 2 | 127.0/8 switch01.tor | 3 | 209.250.155.8/27 (2 rows) but (sysname, ip_addr) - PRIMARY KEY 127.0/8 - it's not correct output ( real 127.0.0.2/8 and 127.0.0.3/8) select * from ipaddresses_view where sysname = 'switch01.tor'; sysname| index |ip_addr| ip_netmask --+---+---+- switch01.tor | 1 | 127.0.0.2 | 255.0.0.0 switch01.tor | 2 | 127.0.0.3 | 255.0.0.0 switch01.tor | 3 | 209.250.155.8 | 255.255.255.224 (2 rows) 127.0.0.2 | 255.0.0.0 and 127.0.0.3 | 255.0.0.0 - it's correct output And of course after pg_dump and restore correct value 127.0.0.2/8 and 127.0.0.3/8 will lose and will have problem with PRIMARY KEY - (sysname, ip_addr). -- Passynkov Vadim, Axxent Inc.
Re: [BUGS] large object seek/write bug
Ian Grant <[EMAIL PROTECTED]> writes:
> I'm using V 7.0 on a Linux machine and I believe I have found a bug in the
> large object interface provided by libpq.
Thank you for the carefully developed test case. The bug is actually
in the backend, not in libpq: there's an ancient hack in inv_write
that looks at rel->rd_nblocks to decide if the large object is empty.
Unfortunately rd_nblocks isn't maintained very carefully, so the test
might mistakenly consider a recently-created LO to be empty, leading
to the Wrong Thing. But that hack is no longer necessary, since the
index bug it was trying to work around was swatted ages ago; diking
out the check suffices to fix it.
Another error I noticed while testing the fix is that inv_read doesn't
cope gracefully with "holes" in the large object, ie, ranges never
written because of a seek and write past the previous end of file.
With the attached patch, reads of "holes" reliably return zeroes,
as is considered standard behavior for Unix files. (The garbage data
you saw was actually from this error, although the case would not have
been triggered if not for the first bug.)
I believe the attached patch fixes these problems, but I haven't been
able to wring it out very thoroughly because I don't have applications
that do random seeks and writes in large objects. If you could bang
on it a little more and report back, that'd be great.
regards, tom lane
*** src/backend/storage/large_object/inv_api.c.orig Wed Apr 12 13:15:37 2000
--- src/backend/storage/large_object/inv_api.c Thu Jun 15 02:10:27 2000
***
*** 185,190
--- 185,191
retval->idesc = RelationGetDescr(indr);
retval->offset = retval->lowbyte = retval->highbyte = 0;
ItemPointerSetInvalid(&(retval->htid));
+ retval->flags = 0;
if (flags & INV_WRITE)
{
***
*** 233,238
--- 234,240
retval->idesc = RelationGetDescr(indrel);
retval->offset = retval->lowbyte = retval->highbyte = 0;
ItemPointerSetInvalid(&(retval->htid));
+ retval->flags = 0;
if (flags & INV_WRITE)
{
***
*** 371,384
if (whence == SEEK_CUR)
{
offset += obj_desc->offset; /* calculate absolute position
*/
- return inv_seek(obj_desc, offset, SEEK_SET);
}
!
! /*
!* if you seek past the end (offset > 0) I have no clue what happens
!* :-(B.L. 9/1/93
!*/
! if (whence == SEEK_END)
{
/* need read lock for getsize */
if (!(obj_desc->flags & IFS_RDLOCK))
--- 373,380
if (whence == SEEK_CUR)
{
offset += obj_desc->offset; /* calculate absolute position
*/
}
! else if (whence == SEEK_END)
{
/* need read lock for getsize */
if (!(obj_desc->flags & IFS_RDLOCK))
***
*** 389,396
offset += _inv_getsize(obj_desc->heap_r,
obj_desc->hdesc,
obj_desc->index_r);
- return inv_seek(obj_desc, offset, SEEK_SET);
}
/*
* Whenever we do a seek, we turn off the EOF flag bit to force
--- 385,392
offset += _inv_getsize(obj_desc->heap_r,
obj_desc->hdesc,
obj_desc->index_r);
}
+ /* now we can assume that the operation is SEEK_SET */
/*
* Whenever we do a seek, we turn off the EOF flag bit to force
***
*** 414,422
* stores the offset of the last byte that appears on it, and we have
* an index on this.
*/
-
-
- /* right now, just assume that the operation is SEEK_SET */
if (obj_desc->iscan != (IndexScanDesc) NULL)
{
d = Int32GetDatum(offset);
--- 410,415
***
*** 424,430
}
else
{
-
ScanKeyEntryInitialize(&skey, 0x0, 1, F_INT4GE,
Int32GetDatum(offset));
--- 417,422
***
*** 487,495
/* copy the data from this block into the buffer */
d = heap_getattr(&tuple, 2, obj_desc->hdesc, &isNull);
ReleaseBuffer(buffer);
! fsblock = (struct varlena *) DatumGetPointer(d);
off = obj_desc->offset - obj_desc->lowbyte;
ncopy = obj_desc->highbyte - obj_desc->offset + 1;
--- 479,505
/* copy the data from this block into the buffer */
d = heap_getattr(&tuple, 2, obj_desc->hdesc, &isNull);
+ fsblock = (struct varlen
