[BUGS] Patch for Linux-IA64
Hi,
attached to this mail is a patch from a colleague that makes
PostgreSQL-7.0.2 run on Linux for the Intel-IA64 architecture. It also
fixes a bug in the configure scripts that caused configure to fail on
the fcntl(F_SETLK) test.
This fix triggered a bug in the fcntl(F_SETLK) code of the Linux
kernel when used on unix domain sockets resulting in postmaster to
segfault immediately after startup. There is a fix available and
included in the kernel that will be on SuSE Linux 7.0, but kernels <=
2.2.16 still have this bug.
Therefore we decided to disable the calls to fcntl(F_SETLK) in
src/backend/libpq/pqcomm.c as workarround for the PostgreSQL RPMs for
SuSE Linux which I am currently working on. The patch (hack) doing
this is also included.
Regards,
Reinhard Max
--
If you put garbage in a computer nothing comes out but garbage.
But this garbage, having passed through a very expensive machine,
is somehow enobled and none dare criticize it.
--- src/Makefile.shlib
+++ src/Makefile.shlib 2000/06/20 11:14:17
@@ -145,9 +145,9 @@
ifeq ($(PORTNAME), linux)
install-shlib-dep:= install-shlib
shlib:=
lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
- LDFLAGS_SL := -Bdynamic -shared -soname $(shlib)
- LDFLAGS_ODBC := -Bsymbolic -lc -lm
- SHLIB_LINK += -lc
+ LD := $(CC)
+ LDFLAGS_SL := -shared -Wl,-soname,$(shlib)
+ LDFLAGS_ODBC := -nostartfiles -Wl,-Bsymbolic -lm
CFLAGS += $(CFLAGS_SL)
endif
--- src/configure
+++ src/configure 2000/06/20 09:18:25
@@ -4928,6 +4928,7 @@
cat > conftest.$ac_ext <
#include
int main() {
struct flock lck;
--- src/configure.in
+++ src/configure.in2000/06/20 09:17:54
@@ -786,7 +786,8 @@
AC_MSG_RESULT(no))
AC_MSG_CHECKING(for fcntl(F_SETLK))
-AC_TRY_LINK([#include ],
+AC_TRY_LINK([#include
+#include ],
[struct flock lck;
lck.l_whence = SEEK_SET; lck.l_start = lck.l_len = 0;
lck.l_type = F_WRLCK;
--- src/include/port/linux.h
+++ src/include/port/linux.h2000/06/20 09:35:00
@@ -33,7 +33,12 @@
#define HAS_TEST_AND_SET
#elif defined(__arm__)
-typedef unsigned char slock_t
+typedef unsigned char slock_t;
+
+#define HAS_TEST_AND_SET
+
+#elif defined(__ia64__)
+typedef unsigned int slock_t;
#define HAS_TEST_AND_SET
--- src/include/storage/s_lock.h
+++ src/include/storage/s_lock.h2000/06/20 09:40:50
@@ -95,6 +95,24 @@
#endif /* __i386__ */
+#ifdef __ia64__
+#define TAS(lock) tas(lock)
+
+static __inline__ int
+tas (volatile slock_t *lock)
+{
+ long int ret;
+
+ __asm__ __volatile__(
+ "xchg4 %0=%1,%2"
+ : "=r"(ret), "=m"(*lock)
+ : "r"(1), "1"(*lock)
+ : "memory");
+
+ return (int) ret;
+}
+#endif /* __ia64__ */
+
#if defined(__arm__) || defined(__arm__)
#define TAS(lock) tas(lock)
--- src/backend/libpq/pqcomm.c
+++ src/backend/libpq/pqcomm.c 2000/07/03 08:47:43
@@ -75,6 +75,12 @@
#include "postgres.h"
#include "libpq/libpq.h"
+
+/* Hack for broken fcntl(F_SETLK) in Linux Kernels < 2.2.16 */
+#ifdef HAVE_FCNTL_SETLK
+#undef HAVE_FCNTL_SETLK
+#endif
+
#include "utils/trace.h" /* needed for HAVE_FCNTL_SETLK */
#include "miscadmin.h"
[BUGS] upper() problem in 7.0.2
Your name : Christopher L. Cousins
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : AMD K7 (Athlon) ("AuthenticAMD"
686-class) 705 MHz
Operating System (example: Linux 2.0.26 ELF) : OpenBSD atlantia 2.7 ATLANTIA#3 i386
PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2
Compiler used (example: gcc 2.8.0) : gcc version 2.95.2 19991024 (release)
Please enter a FULL description of your problem:
Working on the following table:
tickets=# \d tbluser
Table "tbluser"
Attribute |Type | Modifier
---+-+--
username | varchar(16) |
gecos | varchar(50) |
expdate | timestamp |
There are (4523 rows) in this table.
Using PHP4 or PHP3, the following query will ~sometimes~ cause the backend to
terminate. It depends the value of $searchstr and appears (to me anyway) to be
random. A $searchstr that causes the backend to crash right now may work just
fine in a few hours.
The same query issued through psql will not cause the backend to crash.
For both interfaces (psql and PHP4) the query logged (debug) is the same.
SELECT * FROM tblUser WHERE
upper(tblUser.username) LIKE upper('%$searchstr%')
OR
upper(tblUser.gecos) LIKE upper('%$searchstr%');
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
If I change my query back to it's original form, one of our employees
will find a current value that causes the backend to crash (this is
part of a trouble ticket system). Once they find the right string, I can
make the problem happen over and over by hitting reload on my web browser.
If you know how this problem might be fixed, list the solution below:
-
My fix was to use the builtin strtoupper() function in PHP4 to make $searchstr
uppercase before issueing the query to postgres. The following query has been
working for the last couple of days.
SELECT * FROM tblUser WHERE
upper(tblUser.username) LIKE '%$searchstr%'
OR
upper(tblUser.gecos) LIKE '%$searchstr%';
--
--Chris
Impulse Internet Services/\
/ \_
http://www.impulse.net <[EMAIL PROTECTED]>
Re: [BUGS] upper() problem in 7.0.2
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes: > Using PHP4 or PHP3, the following query will ~sometimes~ cause the > backend to terminate. It depends the value of $searchstr and appears > (to me anyway) to be random. A $searchstr that causes the backend to > crash right now may work just fine in a few hours. > The same query issued through psql will not cause the backend to crash. > For both interfaces (psql and PHP4) the query logged (debug) is the same. That's really odd. Since you don't have a reproducible example, we'll have to ask you to do some more digging. Would you build the backend with -g, and then next time you see the problem get a stack backtrace from the core file left by the crashed backend? Notes: (a) the core file should appear in the database subdirectory, ie /data/base/YOURDBNAME/core. (b) if you see no core file there from the prior crashes, you probably have launched the postmaster with a ulimit setting that prevents core dumps. You'll need to be careful to relaunch it with a setting that does allow dumps. regards, tom lane
[BUGS] problem with union and outer join using a view
Developers: I need to create a view that contains a query with an outer join. Since outer joins are not supported, I used a union. The problem, now, is that unions are not supported with views. How soon until this is fixed? Any suggestions? Merrill
[BUGS] Re: [PATCHES] Patch for Linux-IA64
OK, I have applied part of this patch. I skipped the changes to
Makefile.shlib, and the hack to disable flock in pqcomm.c. By the time
this code is released in 7.1, hopefully the Linux kernel will be fixed.
The Makefile.shlib changes will have to be discussed with other Linux
developers so we are sure it will work on all platforms.
I am attaching the part of the patch that I applied.
Thanks.
> Hi,
>
> attached to this mail is a patch from a colleague that makes
> PostgreSQL-7.0.2 run on Linux for the Intel-IA64 architecture. It also
> fixes a bug in the configure scripts that caused configure to fail on
> the fcntl(F_SETLK) test.
>
> This fix triggered a bug in the fcntl(F_SETLK) code of the Linux
> kernel when used on unix domain sockets resulting in postmaster to
> segfault immediately after startup. There is a fix available and
> included in the kernel that will be on SuSE Linux 7.0, but kernels <=
> 2.2.16 still have this bug.
>
> Therefore we decided to disable the calls to fcntl(F_SETLK) in
> src/backend/libpq/pqcomm.c as workarround for the PostgreSQL RPMs for
> SuSE Linux which I am currently working on. The patch (hack) doing
> this is also included.
>
> Regards,
>
> Reinhard Max
> --
> If you put garbage in a computer nothing comes out but garbage.
> But this garbage, having passed through a very expensive machine,
> is somehow enobled and none dare criticize it.
Content-Description: Patch for IA64
--
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
--- configure.in
+++ configure.in2000/06/20 09:17:54
@@ -786,7 +786,8 @@
AC_MSG_RESULT(no))
AC_MSG_CHECKING(for fcntl(F_SETLK))
-AC_TRY_LINK([#include ],
+AC_TRY_LINK([#include
+#include ],
[struct flock lck;
lck.l_whence = SEEK_SET; lck.l_start = lck.l_len = 0;
lck.l_type = F_WRLCK;
--- src/include/port/linux.h
+++ src/include/port/linux.h2000/06/20 09:35:00
@@ -33,7 +33,12 @@
#define HAS_TEST_AND_SET
#elif defined(__arm__)
-typedef unsigned char slock_t
+typedef unsigned char slock_t;
+
+#define HAS_TEST_AND_SET
+
+#elif defined(__ia64__)
+typedef unsigned int slock_t;
#define HAS_TEST_AND_SET
--- src/include/storage/s_lock.h
+++ src/include/storage/s_lock.h2000/06/20 09:40:50
@@ -95,6 +95,24 @@
#endif /* __i386__ */
+#ifdef __ia64__
+#define TAS(lock) tas(lock)
+
+static __inline__ int
+tas (volatile slock_t *lock)
+{
+ long int ret;
+
+ __asm__ __volatile__(
+ "xchg4 %0=%1,%2"
+ : "=r"(ret), "=m"(*lock)
+ : "r"(1), "1"(*lock)
+ : "memory");
+
+ return (int) ret;
+}
+#endif /* __ia64__ */
+
#if defined(__arm__) || defined(__arm__)
#define TAS(lock) tas(lock)
Re: [BUGS] problem with union and outer join using a view
Merrill Oveson <[EMAIL PROTECTED]> writes: > How soon until this is fixed? The plans are to fix it in 7.2, which might be half a year or so away. > Any suggestions? For now, don't use a view. Perhaps you can embed the query in a function or something so that you don't have to look at it ... regards, tom lane
Re: [BUGS] upper() problem in 7.0.2
On Wed, Jul 05, 2000 at 12:03:46PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > Using PHP4 or PHP3, the following query will ~sometimes~ cause the
> > backend to terminate. It depends the value of $searchstr and appears
> > (to me anyway) to be random. A $searchstr that causes the backend to
> > crash right now may work just fine in a few hours.
>
> > The same query issued through psql will not cause the backend to crash.
>
> > For both interfaces (psql and PHP4) the query logged (debug) is the same.
>
> That's really odd. Since you don't have a reproducible example, we'll
> have to ask you to do some more digging. Would you build the backend
> with -g, and then next time you see the problem get a stack backtrace
> from the core file left by the crashed backend?
I have been able to make the backend crash using psql. I also took a dump
of the database while I had some known values that would trigger the problem.
Because of this, I can now reload the dump (to a dummy database) at any time to
reproduce the problem.
I had to attach to the running process to get a backtrace (the core file was
too large to be written to the disk, took me a while to figure that out).
I then issued the following query using psql.
SELECT * FROM tblUser
WHERE upper(tblUser.username) LIKE upper('%asdf%')
OR upper(tblUser.gecos)
LIKE upper('%asdf%');
postgres@cobalt% gdb
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386-unknown-openbsd2.7".
(gdb) file postgres
Reading symbols from postgres...done.
(gdb) attach 9740
Attaching to program `/usr/local/pgsql/bin/postgres', process 9740
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libm.so.0.1...done.
Reading symbols from /usr/lib/libutil.so.4.5...done.
Reading symbols from /usr/lib/libtermcap.so.7.1...done.
Reading symbols from /usr/lib/libcurses.so.7.1...done.
Reading symbols from /usr/lib/libc.so.25.0...done.
0x40211fe3 in _thread_sys_nanosleep ()
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xdfbfd638 in ?? (): No such file or directory.
(gdb) bt
#0 0xdfbfd638 in ?? ()"/bin/": not in executable format: File truncated.
(gdb) bt
#0 0xdfbfd638 in ?? (): No such file or directory.
(gdb) up
#1 0x1 in rtbuild (heap=0x1, index=0x1, natts=1, attnum=0x1, istrat=0x1,
pcount=1, params=0x1, finfo=0x1,
predInfo=0x1) at rtree.c:114
114 buffer = ReadBuffer(index, P_NEW);
(gdb) up
#2 0x1 in ?? () from /usr/lib/libc.so.25.0
--
--Chris
Impulse Internet Services/\
/ \_
http://www.impulse.net <[EMAIL PROTECTED]>
Re: [BUGS] upper() problem in 7.0.2
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes: > I have been able to make the backend crash using psql. I also took a dump > of the database while I had some known values that would trigger the problem. > Because of this, I can now reload the dump (to a dummy database) at any time to > reproduce the problem. > I had to attach to the running process to get a backtrace (the core file was > too large to be written to the disk, took me a while to figure that out). I don't think I believe that backtrace. Could you send me the dump file? regards, tom lane
