Re: [HACKERS] Redhat 7.3 time manipulation bug
On Wed, 22 May 2002, Thomas Lockhart wrote: IIRC the spec is not _really_ broken - it still allows the correct behaviour :) Yes. The fact the ISO spec is broken usually means that at least one of the big vendors involved in ISO spec creation must have had a broken implementation at that time. Right. IBM. Most likely they have fixed it by now ... Nope, though I don't know for sure. Anyone here have a recent AIX machine to test? Does anyone know _any_ other libc that has this behaviour ? AIX and (I think) Irix. Trond, do you have a suggestion on how to get this addressed at the glibc level? Does someone within RH participate in glibc development? Jakub Jelinek, Ulrich Drepper and others. If so, can we get them to champion changes which would comply with the standard but remove this arbitrary breakage? Unlikely. They already saw (and participated, at least Ulrich) a thread on this with Lamar. Their take is this is the standard, you should do what the standard says and not rely on undocumented, non-standardized sideeffects. The changes would involve returning -1 from mktime() for dates before 1970, and using the tm_isdst flag to indicate whether a time zone translation was not possible. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Redhat 7.3 time manipulation bug
On Tue, 21 May 2002, Lamar Owen wrote: On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote: I see. This behavior is consistent with the fact that mktime is supposed to return -1 on error, but then is broken in every other Unix implementation that I know. Any other workaround than downgrade or install FreeBSD? Complain to Red Hat. Loudly. However, as this is a glibc change, other distributors are very likely to fold in this change sooner rather than later. Relying on nonstandardized/nondocumented behaviour is a program bug, not a glibc bug. PostgreSQL needs fixing. Since we ship both, we're looking at it, but glibc is not the component with a problem. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Redhat 7.3 time manipulation bug
On 21 May 2002, Manuel Sugawara wrote: Trond Eivind Glomsrød [EMAIL PROTECTED] writes: Relying on nonstandardized/nondocumented behaviour is a program bug, not a glibc bug. The question is: how this thing didn't show up before? ISTM that someone is not doing his work correctly. FWIW, I ran the regressions tests some time ago(probably before that change to glibc) . Since the tests are known to be broken wrt. time issues anyway (as well as currency, math and sorting), it's easy to overlook. PostgreSQL needs fixing. Arguably, however, right now is *a lot easier* to fix glibc, and it's really needed for production systems using postgreSQL and working on RedHat. You're not fixing glibc, you're reintroducing non-standardized, upstream removed behaviour. That's typically a very bad thing. If anything, it demonstrates the importance of not using or relying on unstandardized/undocumented behaviour (and given that time_t is pretty restrictive anyway, you'll need something else to keep dates. It doesn't even cover all living people, and definitely not historical dates). Since we ship both, we're looking at it, but glibc is not the ^^^ The sad true is: you only answered when the 'Complain to Red Hat' statement appeared, not a single word before and not a single word when the bug report were closed. I'm really disappointed. The bug wasn't open for long, and was closed by someone else. The nice thing is: glibc is free software Also, notice that this was where the fix came from: The upstream maintainers (some of whom work for us, others don't). -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Making the regression tests locale-proof
Peter Eisentraut [EMAIL PROTECTED] writes: The assumption here is that all locales will choose the same sort order as long as they're dealing only with the core 26 letters. This does not have to be true in theory, but I think it works for the vast majority of practical cases. Not for uppercase vs. lowercase versions of them. With no locale used (straight ASCII), you get A C b, with a locale you'll get A b C. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] a vulnerability in PostgreSQL
Tom Lane [EMAIL PROTECTED] writes: Tatsuo Ishii [EMAIL PROTECTED] writes: Here are the precise conditions to trigger the scenario: (1) the backend is PostgreSQL 6.5.x (2) multibyte support is enabled (--enable-multibyte) (3) the database encoding is SQL_ASCII (other encodings are not affected by the bug). (4) the client encoding is set to other than SQL_ASCII I think I am responsible for this since I originally wrote the code. Sorry for this. I'm going to make back port patches to fix the problem for pre 7.2 versions. It doesn't really seem worth the trouble to make patches for 6.5.x. If someone hasn't upgraded yet, they aren't likely to install patches either. (ISTR there are other known security risks in 6.5, anyway.) If the problem is fixed in 7.0 and later, why not just tell people to upgrade? Postgresql doesn't support upgrades[1], so if we're going to release upgrades[2], we'd need the backported fixes for 6.5, 7.0 and 7.1 [1] Not the first time I mention this, is it? [2] We got lucky - 6.5.x is not compiled with multibyte support. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] v7.2.1 re-rolled ...
Marc G. Fournier [EMAIL PROTECTED] writes: And available in /pub/source/v7.2.1 ... this one has both man.tar.gz and postgres.tar.gz in it ... someone want to make a quick confirm while the mirrors pick it up? When rerolling something which has been on a public ftp server, upping the number to avoid confusion is always a good idea. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_dump 2GB limit?
Laurette Cisneros [EMAIL PROTECTED] writes: Hi, I'm on Red Hat. Here's the uname info: Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown You should really upgrade (kernel and the rest), but this kernel supports large files. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump 2GB limit?
Peter Eisentraut [EMAIL PROTECTED] writes: Laurette Cisneros writes: We are using postgresql 7.2 and when dumping one of our larger databases, we get the following error: File size limit exceeded (core dumped) We suspect pg_dump. Is this true? No, it's your operating sytem. Red Hat Linux 7.x which he seems to be using supports this. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.2 RPMs
Peter Eisentraut [EMAIL PROTECTED] writes:
Trond Eivind Glomsrød writes:
* The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
installed whenever Tk support is configured (which is correct, IMO).
Maybe this is just a legacy item?
For 7.1.3, it does make a difference
%if %pgaccess
[...]
%endif
(in addition to the actual package). The 7.2 build procedure might
differ. It's still useful to have several packages, as it under some
circumstances it would be useful to have tk bindings but not ship
pgaccess. E.g. if you were to ship an Asian version, this segregation
might be useful.
Given that pgtksh is rather small in size I don't know if that's worth the
contortions. However, note that pgaccess is still built if you turn on Tk
but turn off %pgaccess. (There was also a plan to make pgaccess use
pgtksh, but it's not happening for 7.2.)
It may be built, but at least you don't get the package... Personally,
I wouldn't mind separating the database core from all the other things
bundled with it (drivers, support programs). It seems a little cleaner.
Not only that, but you very often don't want to build it. If you have
a static perl package, plperl can't be created. It will sort of work
on IA32, but bomb out elsewhere. Ideally, the configure process should
figure out this on it's own (you can't create dynamic extensions
linking in a static lib).
There are provisions in the source for figuring this out automatically.
Currently, the only figuring it does is to allow it on Linux. (It is my
understanding that it works on Linux independent of the CPU architecture.
In the past there have been problems with insufficient dynamic loader
implementations, but there is no principal design obstacle.)
No. It works on IA32, but breaks elsewhere.
But it would really be of advantage if distributors (i.e., you) supplied a
shared libperl by default. There are at least two high profile users
(PostgreSQL and Apache) running into this problem.
It's not unlikely to happen for the next major series (we try hard to
stay binary compatible within a series).
Maybe they should be named to reflect these purposes? Currently,
postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh
conveys the meaning of Red Hat's (better/different) pg_dump.
It was basically doh, the existing dump script is very broken and we
freeze very soon a release or two ago. I think Lamar was the one who
discoverd it and I the one who wrote it rather quickly.
* What about the JDBC driver? I think the driver should be compiled in
place by whatever JDK the build system provides.
Many build systems don't have a JDK, as there are no open (or even
distributable) JDKs.
From Red Hat I would have expected the answer use gcj. ;-) (I don't
know how complete the class library is there, and Ant probably doesn't
support it anyway.) However, two questions arise:
gcj is nice, but far from complete. It's also Java 1.1 without AWT,
AFAIR, and most interesting stuff use 1.2 and up now.
* If the build system doesn't have a JDK, why do you need a JDBC
driver?
That you can use with gcj :). The main reason it's useful is that
other can install their own JDK, typically when running servlets or
other server based Java apps.
Well, do you have time to work on this and do you keep the RPM input files
under version control somewhere, so I can send some incremental
patches?
If you send it, I can have a first look. As for time, that's something
other people have. And when I have it, I don't have anything to use it
for either (maxed out with 5 weeks unused vacation now, but have no
idea what to use most of it for)
--
Trond Eivind Glomsrød
Red Hat, Inc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 RPMs
Peter Eisentraut [EMAIL PROTECTED] writes: Trond Eivind Glomsrød writes: There are provisions in the source for figuring this out automatically. Currently, the only figuring it does is to allow it on Linux. (It is my understanding that it works on Linux independent of the CPU architecture. In the past there have been problems with insufficient dynamic loader implementations, but there is no principal design obstacle.) No. It works on IA32, but breaks elsewhere. Libtool seems to think otherwise. And the people who provided the patches to libtool are the ones who should know best. Dynamic code works on those platforms. What doesn't work is dlopen() of code not compiled with -fpic (which means extensions linking with static libraries). I've not seen libtool claim otherwise, but it would be broken. Another can of worms is nsswitch inside glibc, which in some circumstances will use a dynamic module in a statically linked program. But it would really be of advantage if distributors (i.e., you) supplied a shared libperl by default. There are at least two high profile users (PostgreSQL and Apache) running into this problem. It's not unlikely to happen for the next major series (we try hard to stay binary compatible within a series). You don't break binary compatibility by providing a shared library alongside a static one. This mean backward as well... eg. perl packages for RHL 7.1 should run on RHL 7 as well. Same for RHL 7.2, if we make such a release. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bugs - lets call an exterminator!
Vince Vielhaber [EMAIL PROTECTED] writes: Now some history.. Over the last couple of years we've tried a number (5 I think) of bug tracking packages. Either Marc or me or both have had to learn it, install it, get it going and the result has been the same - the maintainers don't want to update it, it's a pain in the ass to administrator, set up, etc. The current bugtool. After a bunch of these failures I asked for input on what was needed in a tool. Web input interface, ability to track the bug report, email notification to the bug list, email notification to the reporter of the bug. FTR, we're using bugzilla for this and it works great. We're working on porting it PostgreSQL. ftp://people.redhat.com/dkl/ should contain a recent state -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: List response time...
Ian Lance Taylor [EMAIL PROTECTED] writes: Lamar Owen [EMAIL PROTECTED] writes: Mailing lists don't scale well to large numbers of subscribers. I see this delay constantly,on multiple lists. The bigger the list gets, the slower the list gets (and the more loaded the server gets, right Marc? :-)). Note that the postgresql.org mail server is still running sendmail. In my personal experience with sources.redhat.com, qmail is a much better choice to handle large mailing lists. When we switched from sendmail to qmail, mailing list delays dropped from hours, or sometimes even days, to seconds. The MTA used for various redhat.com mailing lists is postfix (and mailman as listmanager) -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Update to 7.1.2 Question...
gabriel [EMAIL PROTECTED] writes: hello all I have a postgresql 7.0 and I'm trying to update to 7.1.2 using rpms but some files is missing like: libcrypto.so.0 libssl.so.0 anyone knows what package i can find this files?? openssl -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
Tom Lane [EMAIL PROTECTED] writes: BTW, the only python shebangs I can find in CVS look like #! /usr/bin/env python Isn't that OK on RedHat? It is. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MySQL Gemini code
Michael Widenius [EMAIL PROTECTED] writes: Please note that we NEVER have asked NuSphere to sign over copyright of Gemini to us. We do it only for the core server, and this is actually not an uncommon thing among open source companies. For example QT (Trolltech) and Ximian (a lot of gnome applications) Ximian isn't doing a lot of gnome applications, just a few (Evolution springs to mind, and their installer). Signing over copyright to Ximian wouldn't make much sense - GNOME isn't a Ximian project, so they can't dual license it anyway. Assigning over the code is also something that FSF requires for all code contributions. If you criticize us at MySQL AB, you should also criticize the above. This is slightly different - FSF wants it so it will have a legal position to defend its programs: http://www.fsf.org/prep/maintain_6.html If you maintain an FSF-copyrighted package, then you should follow certain legal procedures when incorporating changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the right to defend its free status in court if necessary. Before incorporating significant changes, make sure that the person who wrote the changes has signed copyright papers and that the Free Software Foundation has received and signed them. We may also need a disclaimer from the person's employer. MySQL and TrollTech requires copyright assignment in order to sell non-open licenses. Some people will have a problem with this, while not having a problem with the FSF copyright assignment. I had actually hoped to get support from you guy's at PostgreSQL regarding this. You may have similar experience or at least understand our position. The RedHat database may be a good thing for PostgreSQL, but I am not sure if it's a good thing for RedHat or for the main developers to PostgreSQL. This isn't even a remotely similar situation: * For MySQL, the scenario is that a company made available an open version of its product while continuing to sell it under other licenses. * For PostgreSQL, it has been a long living project which spawned companies which then hired some of the core developers. We're not reselling someone elses product with minor enhancements (companies have been known to be doing that to products we create), we're selling support and working on additions to an open project. That may make it harder for the companies now employing the core developers (or may help, as PostgreSQL gets more much deserved publicity and technical credit), but doesn't violate the project's licenses and a company's trademark the way NuSphere did with MySQL. Anyway, I think that we open source developers should stick together. We may have our own disagreements, but at least we are working for the same common goal (open source domination). If you ever need any support from us regarding the RedHat database,, please contact me personally about this. Red Hat is firmly committed to open source, and is definitely a big open source developer. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. Haven't many systems (at least Linux and FreeBSD) switched from this to other algorithms as default, like MD5? (and usually found in /etc/shadow) Yes, most BSD's are MD5. I wasn't sure about Linux. Most recent (3-4 years and newer) use PAM, which can use MD5 as an underlying module. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. Haven't many systems (at least Linux and FreeBSD) switched from this to other algorithms as default, like MD5? (and usually found in /etc/shadow) Yes, most BSD's are MD5. I wasn't sure about Linux. Most recent (3-4 years and newer) use PAM, which can use MD5 as an underlying module. But what is the default? crypt or md5? Varies. In Red Hat Linux, it's been user configurable during install for a couple of years now - it's been default to on for most of that time, AFAIR. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: My take on the matter is that we shouldn't invest any more effort in crypt-based solutions (here crypt means specifically crypt(3), it's not a generic term). The future is double encryption using MD5 --- or s/MD5/more-modern-hash-algorithm-of-your-choice/, the exact choice is irrelevant to my point. We ought to get off our duffs and implement that, then encourage people to migrate their clients ASAP. The crypt code will be supported for awhile longer, but strictly as a backwards-compatibility measure for old clients. There's no reason to spend any additional work on it. For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. Haven't many systems (at least Linux and FreeBSD) switched from this to other algorithms as default, like MD5? (and usually found in /etc/shadow) -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres dies while doing vacuum analyze
Manuel Sugawara [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Manuel Sugawara [EMAIL PROTECTED] writes: [ vacuum analyze dies ] It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel. Here is the back trace from gdb (gdb) bt #0 strcoll () at strcoll.c:229 We've heard reports before of strcoll() crashing on apparently valid input. It seems to be a Red Hat-specific problem; the three reports I have in my notes are from people running RH 7.0 (check the archives from 1/1/01, 1/24/01, 3/1/01 if you want to see the prior reports). It's possible that Postgres is doing something that confuses RH's locale library, but I dunno what. Since no other platform is reporting it, it could also be a plain old bug in that locale library. After a look into strcoll I found the bug. Attached is a tarball including a patch for strcoll, glibc.spec and an small program that shows the bug. Will do... what is the expected result of the testcase? It seems to work alright for me, but I'm running a slightly newer version than we have released yet... (glibc-2.2.3-11, look in rawhide). -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] postgres dies while doing vacuum analyze
On 16 Jun 2001, Manuel Sugawara wrote: [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes: [...] OK, this works with my system - no coredump, correct results. I'll take a look at the glibc sources to verify that, but it looks like this was fixed by [EMAIL PROTECTED] and included in glibc 2.2.3: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36539 yes, is already fixed on glibc-2.2.3. It's safe to install this version on my 7.1 systems The 2.2.3-11 should be safe, we would be very interested to hear othwerwise. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] postgres dies while doing vacuum analyze
Tom Lane [EMAIL PROTECTED] writes: Manuel Sugawara [EMAIL PROTECTED] writes: [ vacuum analyze dies ] It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel. Here is the back trace from gdb (gdb) bt #0 strcoll () at strcoll.c:229 We've heard reports before of strcoll() crashing on apparently valid input. We haven't AFAIK, but would be very interested if it can be reproduced. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Any time estimates for 7.1.2 RPM's ?
Hannu Krosing [EMAIL PROTECTED] writes: Lamar Owen wrote: While the advice to pick up the Rawhide 7.1.2 source RPM is sound for a user of RedHat 7.x, unless you have updated to RPM 3.0.5 or greater on your 6.2 boxen you won't be able to install the source RPM from Rawhide, since it was written in RPM4 format. Thanks for this info. I had just completed a --rebuild on RH 7.1 and planned to do the same on 6.2, but I guess I'd rather wait a few days. Note that most 6.2 systems already have a new version, as both 3.0.5 and 4.0.2 have been released at erratas at different times. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] ORDER BY Problem...
Christopher Kings-Lynne [EMAIL PROTECTED] writes: As far as I know, this is the standard (ASCII-ordered) way of sorting text. No, it's the we don't know anything about text, but we can compare their numeric values approach. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Using 7.1rc1 under RH 6.2
Lamar Owen [EMAIL PROTECTED] writes: On Monday 21 May 2001 07:46, Arsalan Zaidi wrote: We tried the RPM under RH 6.2 and it would unpack, saying we needed this or that or the other... A whole bunch of dependencies. I just want to be sure... there's no compelling reason to use RH 7.x (basically any new distribution with newer libraries) right? Are there any subtle problems we'd face if we continue using this setup? RedHat 7.1 is a substantial upgrade for more than one reason. Performance is better, and stability (at least for me) has been just as good. The 2.4 kernels make sure that fdatasync() works properly, which could improve performance in certain scenarious quite a bit. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Need Postgresql ODBC Driver
jacky_shu [EMAIL PROTECTED] writes: I am a novice in postgreSQL.So i want to get ODBC driver to connect with my program. http://www.unixodbc.org/ Is there somebody can tell me where the driver can download.Or how to connect postgreSQL with PHP page in linux. You can find PHP rpms with ODBC support in Rawhide ( ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/ ) - I tested it with unixODBC and postgresql 7.1.1 (also in that directory), and it worked fine for me. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps it would be good to make the empty path component equivalent to $libdir, e.g., Hmm, that would work, and also avoid having to figure out how to stuff $PGLIB into postgresql.conf during initdb. While on the subject of postgresql conf... shouldn't it be in sysconfdir instead of the database directory? And there's no switch to the postmaster to tell it you've put it somewhere else either. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. I could live with a datadir-then-sysconfdir path search. (It should be datadir first, since the sysconfdir file would serve as a system-wide default for multiple postmasters.) Given that approach I see no real need for a postmaster switch. Possibly the same approach should apply to all the config files we currently store in datadir? There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) We'd need to think about the implications of allowing Postgres config files to be world-visible. The files doesn't need to be visible to others... -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) The usual install procedure would probably leave sysconfdir owned by root, if one likes to install in such a way that the binaries are owned by root (ie make, su root, make install). I'd object to a setup that's insecure for people who aren't using RPMs. So make the files unreadable, if so required. The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. It conflicts with the FHS - and no, I don't consider configuration files and data as an identical item. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: New Linux xfs/reiser file systems
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes: [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes: Ken Hirsch [EMAIL PROTECTED] writes: I don't have a machine with XFS installed and it will be at least a week before I could get around to a build. Any volunteers? I think I could do that... any useful benchmarks to run? In lack of bigger benchmarks, I tried postgresql 7.1 on a Red Hat Linux 7.1 system with the SGI XFS modifications. The differences were very small. And here is the one for ReiserFS - same kernel, but recompiled to turn off debugging DB connection startup: 0.01user 0inputs+0outputs (208major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE (1 xact): real0m5.857s : user0m1.200s : sys 0m0.510s : 8192 INSERTs INTO SIMPLE (8192 xacts): real0m37.036s : user0m1.430s : sys 0m0.580s : Create INDEX on SIMPLE: 0.00user 0inputs+0outputs (209major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE with INDEX (1 xact): real0m7.017s : user0m1.180s : sys 0m0.420s : 8192 random INDEX scans on SIMPLE (1 xact): real0m12.761s : user0m1.670s : sys 0m0.820s : ORDER BY SIMPLE: 0.04user 0inputs+0outputs (214major+69minor)pagefaults 0swaps : When compared to the earlier ones (including XFS), you'll note that ReiserFS performance is rather poor in some of the tests - it takes 37 vs. 13 seconds for 8192 inserts, when the inserts are different transactions. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Shared library versions
Peter Eisentraut [EMAIL PROTECTED] writes: The Hermit Hacker writes: IMHO, it should only be changed if there are incompatibilities between releases ... we modify the API, mainly ... anything more then that, and we're making ppl recompile to pull in libraries that only unlying code has changed, but not the API ... ISTM that you should read up on shared library versioning. I second that... if new functionality is added, bump the minor. If functionality changes or is removed, bump the major. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: New Linux xfs/reiser file systems
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes: Ken Hirsch [EMAIL PROTECTED] writes: I don't have a machine with XFS installed and it will be at least a week before I could get around to a build. Any volunteers? I think I could do that... any useful benchmarks to run? In lack of bigger benchmarks, I tried postgresql 7.1 on a Red Hat Linux 7.1 system with the SGI XFS modifications. The differences were very small. DB connection startup: 0.01user 0inputs+0outputs (208major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE (1 xact): real0m5.871s : user0m0.990s : sys 0m0.460s : 8192 INSERTs INTO SIMPLE (8192 xacts): real0m13.347s : user0m1.420s : sys 0m0.530s : Create INDEX on SIMPLE: 0.01user 0inputs+0outputs (209major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE with INDEX (1 xact): real0m6.938s : user0m1.160s : sys 0m0.420s : 8192 random INDEX scans on SIMPLE (1 xact): real0m12.831s : user0m1.700s : sys 0m0.970s : ORDER BY SIMPLE: 0.07user 0inputs+0outputs (214major+69minor)pagefaults 0swaps : DB connection startup: 0.02user 0inputs+0outputs (208major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE (1 xact): real0m5.652s : user0m1.080s : sys 0m0.530s : 8192 INSERTs INTO SIMPLE (8192 xacts): real0m13.021s : user0m1.280s : sys 0m0.380s : Create INDEX on SIMPLE: 0.01user 0inputs+0outputs (209major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE with INDEX (1 xact): real0m6.912s : user0m1.100s : sys 0m0.530s : 8192 random INDEX scans on SIMPLE (1 xact): real0m12.745s : user0m1.660s : sys 0m0.940s : ORDER BY SIMPLE: 0.04user 0inputs+0outputs (214major+70minor)pagefaults 0swaps : DB connection startup: 0.01user 0inputs+0outputs (208major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE (1 xact): real0m5.649s : user0m1.000s : sys 0m0.540s : 8192 INSERTs INTO SIMPLE (8192 xacts): real0m13.115s : user0m1.390s : sys 0m0.490s : Create INDEX on SIMPLE: 0.01user 0inputs+0outputs (209major+17minor)pagefaults 0swaps : 8192 INSERTs INTO SIMPLE with INDEX (1 xact): real0m6.827s : user0m1.240s : sys 0m0.560s : 8192 random INDEX scans on SIMPLE (1 xact): real0m12.653s : user0m1.790s : sys 0m0.830s : ORDER BY SIMPLE: 0.01user 0inputs+0outputs (214major+69minor)pagefaults 0swaps : -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] File system performance and pg_xlog
Marko Kreen [EMAIL PROTECTED] writes: On Sat, May 05, 2001 at 10:10:33PM -0400, mlw wrote: I think it is simpler problem than that. Postgres, with fsync enabled, does a lot of work trying to maintain data integrity. It is logical to conclude that a file system that does as little as possible would almost always perform better. Regardless of what the file system does, eventually it writes blocks of data to sectors on a disk. But there's more, when PostgreSQL today 'uses a fs' it also get all the caching/optimizing algorithms in os kernel 'for free'. Many databases use their own data volume management. I am not suggesting that anyone create a new file system, but after performing some tests, I am really starting to see why products like oracle manage their own table spaces. If one looks at the FAT file system with an open mind and a clear understanding of how it will be used, some small modifications may make it the functional equivalent of a managed table space volume, at least under Linux. Are you talking about new in-kernel fs? Lets see, how many os'es PostgreSQL today supports? If you're using raw devices on Linux and get a win there, it's a win for Postgresql on Linux. This is important for everyone using it on this platform (probably a big chunk of the users). And who uses all the new features and performance enhancements done in other ways? It all comes down to if it actually would give a performance boost, how much work it is and if someone wants to do it. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] File system performance and pg_xlog
Bruce Momjian [EMAIL PROTECTED] writes: That is a major issue for people running performance tests. For example, XFS may be slow on 2.2 kernels but not 2.4 kernels. XFS is 2.4 only, AFAIK - even the installer modifications SGI did to Red Hat Linux 7 (which is shipped with a 2.2 kernel) includes installing a 2.4pre kernel, AFAIR. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Re: New Linux xfs/reiser file systems
mlw [EMAIL PROTECTED] writes: I have looked at Reiser, and I don't think it is a file system suited for very large files, or applications such as postgres. What's the problem with big files? ReiserFS v2 doesn't seem to support it, while v3 seems just fine (of the ondisk format) That said, I'm certainly looking forward to xfs - I believe it will be the most widely used of the current batch of journaling file systems (reiserfs, jfs, XFS and ext3, the latter mainly focusing on an easy migration path for existing system) -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Linux xfs/reiser file systems
I got some information from Stephen Tweedie on this - please keep him Cc: as he's not on this list Bruce Momjian [EMAIL PROTECTED] writes: I was talking to a Linux user yesterday, and he said that performance using the xfs file system is pretty bad. He believes it has to do with the fact that fsync() on log-based file systems requires more writes. Performance doing what? XFS has known performance problems doing unlinks and truncates, but not synchronous IO. The user should be using fdatasync() for databases, btw, not fsync(). First, XFS, ext3 and reiserfs are *NOT* log-based filesystems. They are journaling filesystems. They have a log, but they are not log-based because they do not store data permanently in a log structure. Berkeley LFS, Sprite and Spiralog are log-based filesystems. With a standard BSD/ext2 file system, WAL writes can stay on the same cylinder to perform fsync. Is that true of log-based file systems? Not true on ext2 or BSD. Write-aheads are _usually_ close to the inode, but not always. For true log-based filesystems, writes are always completely sequential, so the issue just goes away. For journaling filesystems, depending on the setup there may be a seek to the journal involved, but some journaling filesystems can use a separate disk for the journal so no seek is required. I know xfs and reiser are both log based. Do we need to be concerned about PostgreSQL performance on these file systems? I use BSD FFS with soft updates here, so it doesn't affect me. A database normally preallocates its data files and then performs most of its writes using update-in-place. In such cases, fsync() is almost always the wrong thing to be doing --- the data writes have changed nothing in the inode except for the timestamps, and there's no need to flush the timestamps to disk for every write. fdatasync() is designed for this --- if the only inode change is timestamps, fdatasync() will skip the seek to the inode and will only update the data. If any significant inode fields have been changed, then a full flush is done. Using fdatasync, most filesystems will incur no seeks for data flush, regardless of whether the filesystem is journaling or not. Cheers, Stephen -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Re: New Linux xfs/reiser file systems
Ken Hirsch [EMAIL PROTECTED] writes: I don't have a machine with XFS installed and it will be at least a week before I could get around to a build. Any volunteers? I think I could do that... any useful benchmarks to run? -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Packaging 7.1.1
Rachit Siamwalla [EMAIL PROTECTED] writes: Also i never got a response on who actually packages those linux init scripts that appear in the RPM but not on the pgsql cvs tree. (i am also curious on why it is different, and how the RPM is built). Lamar Owen and I. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Extrordinarily Poor Performance....
Lamar Owen [EMAIL PROTECTED] writes: Ryan Mahoney wrote: Any input would be helpful! If you need additional info let me know. BTW, Thanks to Lamar for some great tips today! You're more than welcome. I forgot a basic tip, which leads to a question: How often are you running VACUUM ANALYZE? If this were PostgreSQL 7.0.3, we could ask Alfred about his lazy vacuum patches, as they work as well for Red Hat 7 as they do for FreeBSD. Postgresql 7.0.3 from Red Hat Linux 7.1 should work just fine on Red Hat Linux 7. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] 7.1 on 7.1
[EMAIL PROTECTED] (Trond Eivind Glomsrd) writes: PostgreSQL 7.1 on Red Hat Linux 7.1[1]: All 76 tests passed. I'll submit it to the website soonish. [1] Available this morning, http://www.redhat.com/about/presscenter/2001/press_sevenone.html I've not been able to submit it - the URL http://www.postgresql.org/~vev/regress/ (which is referred to from the developer pages) results in a 404. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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
[HACKERS] 7.1 on 7.1
PostgreSQL 7.1 on Red Hat Linux 7.1[1]: All 76 tests passed. I'll submit it to the website soonish. [1] Available this morning, http://www.redhat.com/about/presscenter/2001/press_sevenone.html -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: 7.1 RPMs
Lamar Owen [EMAIL PROTECTED] writes: In the past I have found that kaffe did not handle enough java code for my needs, but that was not for the JDBC driver. I am currently using jikes for my projects, and it produces *nice* code in my experience. Jikes is open source, right? I know it is available for Red Hat (ships with it on one of the applications CD's,IIRC.) How does a Jikes-built JDBC sound to people? Ormaybe I don't understand the Java Way well enough to decide. Gotta learn it a little Jikes is an excellent compiler, but it needs a set of classes to compile against from a JDK. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Anyone have any good addresses ... ?
The Hermit Hacker [EMAIL PROTECTED] writes: Here is what we've always sent to to date ... anyone have any good ones to add? Addresses : [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux, redhat-announce is also a suitable location. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Anyone have any good addresses ... ?
The Hermit Hacker [EMAIL PROTECTED] writes: On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrd wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Here is what we've always sent to to date ... anyone have any good ones to add? Addresses : [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux, redhat-announce is also a suitable location. do you have email addresses fo freshmeat/linuxtoday? I have 6 web sites that I have bookmarked for announces also, so if you have a good web URL, I'll take those too ... Seems to be web based (painful): http://freshmeat.net/faq/view/20/ http://linuxtoday.com/contribute.php3 -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Re: Call for platforms
Lamar Owen [EMAIL PROTECTED] writes: Thomas Lockhart wrote: Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Did you get the message from Trond about Linux 2.4 x86? I can also verify all tests passed on a RedHat Public Beta installation with kernel 2.4. I haven't put those in the list yet... I'll wait until we release a product, and test it on that. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Call for platforms
Vince Vielhaber [EMAIL PROTECTED] writes: On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsrd wrote: [EMAIL PROTECTED] (Trond Eivind Glomsrd) writes: Thomas Lockhart [EMAIL PROTECTED] writes: If a platform you are running on is not listed, make sure it gets included! Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed with 7.1beta6 (parallel_schedule). Forgot to mention: This is x86. Forget to enter it into the regresstest database? http://www.postgresql.org/~vev/regress/ I was planning on waiting with that until I test it on an official release. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for platforms
Thomas Lockhart [EMAIL PROTECTED] writes: If a platform you are running on is not listed, make sure it gets included! Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed with 7.1beta6 (parallel_schedule). I'll update this info when we do our next release. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Call for platforms
[EMAIL PROTECTED] (Trond Eivind Glomsrd) writes: Thomas Lockhart [EMAIL PROTECTED] writes: If a platform you are running on is not listed, make sure it gets included! Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed with 7.1beta6 (parallel_schedule). Forgot to mention: This is x86. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM building (was regression on RedHat)
Thomas Lockhart [EMAIL PROTECTED] writes: It's a good start to test with for the purposes for which I think you want to test for. (and I'm an English teacher by night -- argh). :) Mandrake (as of 7.2) still does a brain-dead mix of "-O3" and "-ffast-math", which is a risky and unnecessary combination according to the gcc folks (and which kills some of our date/time rounding). From the man page for gcc: -ffast-math This option should never be turned on by any `-O' option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ANSI rules/specifications for math functions. I'd like to get away from having to post a non-brain-dead /root/.rpmrc file which omits the -ffast-math flag. Can you suggest mechanisms for putting a "-fno-fast-math" into the spec file? Isn't there a mechanism to mark things as "distro specific"? Suggestions? If Mandrake wants to be broken, let them - and tell them. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] RPM building (was regression on RedHat)
Justin Clift [EMAIL PROTECTED] writes: It's not "Mandrake" that will be broken. Mandrake is also often used by new Linux users who wouldn't have the slightest idea about setting GCC options. It'll be THEM that have broken installations if we take this approach (as an aside, that means that WE will be probably also be answering more questions about PostgreSQL being broken on Mandrake systems). Isn't it better that PostgreSQL works with what it's got on a system AND ALSO that someone notifies the Mandrake people regarding the problem? Most people will use what the vendor ship - a vendor (like us) look into the benefits (stability, performance, compatiblity) of different packages, and make a selection. If they've done a choice of which options are used in their distribution, they are obviously fine with the consequences. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Call for platforms (linux 2.4.x ?)
Franck Martin [EMAIL PROTECTED] writes: Would be nice to certify it is running on kernel 2.4.x as they claim this is entreprise strength kernel... Lamar, if you send me your SRPM I can do that... -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Do you plan an RPM release of beta 6
Jean-Michel POURE [EMAIL PROTECTED] writes: Just to ask you if someone is planning to release beta 6 RPMs. I am running Redhat 7.0 test servers and the compiler is broken. The compiler is not broken. If you find some bugs, please submit them and we'll fix them. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster
[EMAIL PROTECTED] (Nathan Myers) writes: On Linux, /usr/src/linux/include is meaningless for anything in userland; it's meant only for building the kernel and kernel modules. That Red Hat tends to expose it to user-level builds is a long-standing bug in Red Hat's distribution 1) it isn't this way anyore 2) this was so for most distributions for a loong time, not a "Red Hat" bug. in violation of the File Hierarchy Standard as well as explicit instructions from Linus crew and from the maintainer of the C library. Which obviously hasn't always been the case - the FHS isn't exactly old. Things have changed since then, we have followed. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Turkish locale bug
Sezai YILMAZ [EMAIL PROTECTED] writes: Justin Clift wrote: Tom Lane wrote: Sezai YILMAZ [EMAIL PROTECTED] writes: With Turkish locale it is not possible to write SQL queries in CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first are downgraded to "nsert" and Then "nsert" and "unon" does not match as SQL identifier. Ugh. snip How about thinking in the other direction is it possible for PostgreSQL to be able to recognised localised versions of SQL queries? i.e. For a Turkish locale it associates "nsert" INSERT and "unon" with UNION. I don't have any opinion how can solve this problem. But, I don't agree with this solution. SQL is naturally English. I am against SQL to be localized. Has anyone come up with a good solution? The last one I saw from Tom Lane required compile-time options which isn't an option for us. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] GPL, readline, and static/dynamic linking
Bruce Momjian [EMAIL PROTECTED] writes: Here is an article about GPL and GPL version 3.0. http://icd.pennnet.com/Articles/Article_Display.cfm?Section=ArticlesSubSection=DisplayARTICLE_ID=92350VERSION_NUM=1 The interesting thing is that Stallman says: "Our position is that it makes no difference whether programs are linked statically or dynamically," explains Stallman. "Either one makes a combined program. This would seem to imply that our dynamic linking of libreadline in PostgreSQL backend binaries makes the distribution of backend binaries fall under the GPL. This was discussed extensively earlier. Linking dynamically or statically doesn't make a difference in the case of a library, but as long as readline is an optional feature for the user it's not a problem. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: Trond Eivind Glomsrd wrote: Tom Lane [EMAIL PROTECTED] writes: It would probably be better if the socket files weren't in /tmp but in a postgres-owned directory. However, at this point we have a huge backwards compatibility problem to overcome if we want to move the socket files. Not to sound scheptical, but since when did postgresql care about backwards compatiblity? Upgrading is already demanding a lot of knowledge from the user (including needing such information, which almost no other package do), this is just a minor change (the files are mostly used by bundled tools - any exceptions?) Upgrading is only one facet of backwards compatibility. I know. I just mentioned one consistently painful aspect of it. There is an option in 7.1 to support defining a different directory for the socket files, but I doubt very many people will use it. I intend to, for the RPMs we ship. Ok, why not fix tmpwatch instead? Because it wouldn't be a fix, it would be a "lets workaround one specific app which does things in a bad way"-hack. /tmp isn't supposed be more than that... storing things there for more than than 10 days? Ouch. Only the lock files break FHS Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... To where do you intend to move them to? /var/lock/pgsql? /var/run/pgsql? Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). (note that you AFAIK (I don't use mysql much, I prefer postgresql) can have multiple sections if you want want to have multiple backends running. That is not "ideal", in fact it would break one of the specific features that UUNET asked us for. Namely, to be able to have noninterfering sets of socket files in different explicitly-specified directories. If the lock files don't live where the sockets do, then this doesn't work. I don't see why this must be so... Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. Huh? The socket and lockfile are created and held open by the postmaster for the duration of its run. Client programs don't even know that the lockfile is there, in fact. How can you argue that client program lifespan has anything to do with it? Nothing but the postmaster uses it? If so, there shouldn't be a problem moving it. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: Oliver Elphick wrote: No, UNIX sockets are specifically mentioned as belonging under /var/run. In section 5.10 "/var/run : Run-time variable data", it says: "Programs that maintain transient UNIX-domain sockets should place them in this directory." So what ever the outcome for the wider PostgreSQL community, I must make the change to conform to Debian policy. So, if PostgreSQL is a part of Debian, then there will be problems if the client-server situation isn't somehow fixed to allow robust location-independent socket finding. Looks like the same thing is going to happen with RedHat's distribution. So, if this is going to occur, let's get a consensus as to where that alternate location (barring some other solution) is going to be, so that there are the fewest variants out there. FHS is a good starting (and end-) point. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] 7.0.3 reproduceable serious select error
Rob van Nieuwkerk [EMAIL PROTECTED] writes: I know very little about this LANG, LOCALE etc. stuff. But for our application it is very important to support "weird" characters like " ..." etc. for names. Basically we need all letter symbols in ISO-8859-1 (Latin 1). en_US is latin1 - this is what distinguishes it from POSIX/C. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Peter Eisentraut [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd writes:
We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.
We don't use libtool.
Doing so would be a good thing.
Nor does libtool care about the processor.
As you can see from the actual code segment, only the
config.{guess,sub} files are copied.
--
Trond Eivind Glomsrd
Red Hat, Inc.
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Peter Eisentraut [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd writes:
We don't use libtool.
Doing so would be a good thing.
Not if our code is more portable than libtool's.
And this is the case? libtool covers pretty much everything... and you
don't need to use it for every target.
Nor does libtool care about the processor.
As you can see from the actual code segment, only the
config.{guess,sub} files are copied.
But you argued that this is because your config.guess supports s390 and
ia64 (which ours does as well)
It may do so now, but I'm pretty sure it hasn't always done so... and
even if it does, it doesn't hurt.
--
Trond Eivind Glomsrd
Red Hat, Inc.
Re: [HACKERS] RPMS for 7.1beta3 being uploaded.
Lamar Owen [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Trond Eivind Glomsrd writes: We have a libtool tuned to work with lots of platforms, like ia64, s390 etc... this makes sure it's used. We don't use libtool. Nor does libtool care about the processor. In particular, this was and is a RedHat-made change. It does not break anything that I am aware of, and allows the distributions to do their thing as well. Note that this wasn't included in Red Hat Linux 7... it's been done since then, and I don't remember doing it myself (which of course doesn't mean I didn't do it :) - it might have been done for the S/390 port, by the people working on that. So, Trond, what sort of tunings have been performed that make the files in question need to be copied? I'm sure you have a good reason; I am just curious as to what it is. For most apps, it's just a question of configure working vs. configure failing on IA64 (there is no "tuning" as such, my choice of words wasn't too good). There may be something similar for S/390. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] European Datestyle
Daniele Orlandi [EMAIL PROTECTED] writes: Hello, Why is this happening ? ctonet=# show datestyle; NOTICE: DateStyle is ISO with European conventions SHOW VARIABLE ctonet=# select creation_date from users limit 1; creation_date 2000-12-07 04:40:23+01 ^^ That is the ISO-style, isn't it? There are two ways of making dates make sense, none of them American (but hey, they're still using Fahrenheit, feet, lb, fl.oz. acres and other nonsensical units... ) -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] beta testing version
Lamar Owen [EMAIL PROTECTED] writes: Mitch Vincent wrote: Regardless of what license is best, could the license even be changed now? I mean, some of the initial Berkeley code is still in there in some sense and I would think that the original license (BSD I assume) of the initial source code release would have to be somehow honored.. I'm just wondering if the PG team could change the license even if they wanted to.. I should go read the license again, I know the answer to the above is in there but it's been a _Every_single_ copyright holder of code in the core server would have to agree to any change. No - GPL projects can include BSD-copyrighted code, no problem there. That being said, creating bad blood is not a good thing, so an approach like this would hurt PostgreSQL a lot. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] beta testing version
"Gary MacDougall" [EMAIL PROTECTED] writes: No offense Trond, if you were in on the Red Hat IPO from the start, you'd have to say those people made "good money". I'm talking about the business as such, not the IPO where the price went stratospheric (we were priced like we were earning 1 or 2 billion dollars year, which was kindof weird). -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] OK, that's one LOCALE bug report too many...
[EMAIL PROTECTED] (Trond Eivind GlomsrØd) writes: Tom Lane [EMAIL PROTECTED] writes: Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly on recent RedHat releases, I propose that initdb change "en_US" to "C" if it finds that setting. It does not misbehave in glibc (it's not Red Hat specific). Basically, glibc is the old Oops, here's the rest: glibc with the C/POSIX locale will make things work the old computer way: AB...Zab..z With en_US, it works the iso way: A/a B/b ... Z/z -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] 486 Optimizations...
Larry Rosenman [EMAIL PROTECTED] writes: Anyone care if I build a patch to kill the -m486 type options in the following files: $ grep -i -- 486 * bsdi: i?86) CFLAGS="$CFLAGS -m486";; freebsd:CFLAGS='-O2 -m486 -pipe' univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4' Why would you want to? Not all gccs support -mpentium/mpentiumpro etc. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] 486 Optimizations...
Larry Rosenman [EMAIL PROTECTED] writes: * Trond Eivind Glomsr?d [EMAIL PROTECTED] [001114 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: Anyone care if I build a patch to kill the -m486 type options in the following files: $ grep -i -- 486 * bsdi: i?86) CFLAGS="$CFLAGS -m486";; freebsd:CFLAGS='-O2 -m486 -pipe' univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4' Why would you want to? Not all gccs support -mpentium/mpentiumpro etc. I would remove it entirely. Why should a package FORCE 486 or any other processor optimizations? It doesn't force, it only uses those if you don't specify any yourself AFAIK (at least, that's the normal way to do it) FWIW, this was what Red Hat Linux used up to and including 6.2 - it increases performance on almost every chip, it runs everywhere, it goes with any gcc. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] 486 Optimizations...
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes: Larry Rosenman [EMAIL PROTECTED] writes: * Trond Eivind Glomsr?d [EMAIL PROTECTED] [001114 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: Anyone care if I build a patch to kill the -m486 type options in the following files: $ grep -i -- 486 * bsdi: i?86) CFLAGS="$CFLAGS -m486";; freebsd:CFLAGS='-O2 -m486 -pipe' univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4' Why would you want to? Not all gccs support -mpentium/mpentiumpro etc. I would remove it entirely. Why should a package FORCE 486 or any other processor optimizations? It doesn't force, it only uses those if you don't specify any yourself AFAIK (at least, that's the normal way to do it) FWIW, this was what Red Hat Linux used up to and including 6.2 - it increases performance on almost every chip, it runs everywhere, it goes with any gcc. To clarify - this is on IA32 only, of course. OSes know running on more chips should get separate entries, like Linux does. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Lamar Owen [EMAIL PROTECTED] writes: Now, J Random slides in the new OS CD on a backup of his main server, and upgrades. RedHat 7.2's installer is very smart -- if no packages are left that use glibc 2.0, it doesn't install the compat-libs necessary for glibc 2.0 apps to run. Actually, glibc is a bad example of things to break - it has versioned symbols, so postgresql is pretty likely to continue working (barring doing extremely low-level stuff, like doing weird things to the loader or depend on buggy behaviour (like Oracle did)). Postgresql doesn't use C++ either (which is a horrible mess wrt. binary compatibility - there is no such thing, FTTB). However, if it depended on kernel specific behaviour (like things in /proc, which may or may not have changed its output format) it could break. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Tom Lane [EMAIL PROTECTED] writes: Lamar Owen [EMAIL PROTECTED] writes: Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0 might fail if 2.1 were to be loaded under it (hypothetically)). You link against libpq.so.2 , not libpq.so.2.1. This isn't a problem. If the RPM stuff has arbitrarily decided that it won't honor that definition, why do we bother with multiple numbers at all? There is no such problem. So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then? To answer your question, there are no pending changes in libpq that would mandate a major version bump (ie, nothing binary-incompatible, AFAIK). We could ship it with the exact same version number, but then how are people to tell whether they have a 7.0 or 7.1 libpq? If there isn't any changes, why bump it? -- Trond Eivind Glomsrød Red Hat, Inc.
[HACKERS] Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Bruce Momjian [EMAIL PROTECTED] writes: Let them. It is their decision. Frankly, I have seen this attitude before, and I don't like it. Just the mention that "Gee, if you don't cooperate, we may yank you," is really a veiled threat. Now, I know you aren't saying that, but the "if you don't play nice, we will drop you" argument sounds a lot more like MS that a Linux vendor should be acting, especially since they are not telling us what they want or assisting in the work. FWIW, I've never threatened to do so. If I wanted to, I would just do it[1] - threats are bad and never cause anything but bad feelings. That being said, my favorite wishes (in addition to as much SQL compliance and performance as possible, of course) are: * migration on upgrade * old libraries being able to speak to newer databases, so old binaries can continue working after database upgrades * good sonames on libraries - if a library hasn't changed, bumping the number to show it's part of a new version isn't necesarry. If it is backwards compatible, just bump the minor version, if it isn't, bump the major version. Or even better, use versioned symbols (I don't know how many other OSes than Linux and Solaris supports this, though). As for assisting, at least Red Hat contributes to a lot of projects, some of which are important to postgres on one or more platforms: gdb, gcc, glibc and the linux kernel. There just isn't enough resources to do everything, but I try to help out with the RPMs. When we make patches for packages, we try to cooperate with the author(s) to get them in - happily, we haven't had much of a need for that with postgresql. The "We are big. Just fix it and let us know when it is ready" attitude does not work here, and that is what I am hearing mostly from the RPM people. I haven't heard anyone say that. There must be a list of known problems. Let's hear them, so we can try to solve them as a group. However, in general, we do not make dramatic change to work around OS bugs, and do not plan to make major changes to work around the limitations of RPM's. I don't think there are any apart from the upgrade issues - if library versioning follows the standard, that certainly won't be a problem. [1] which I'm not even close to doing - I've spent a bit of time lately hunting down aliasing bugs in MySQL which causes wrong SQL query results if compiled with "-O2". Ouch. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] what is CVS?
Robert Kernell [EMAIL PROTECTED] writes: Kevin O'Gorman wrote: I've been unable to follow the directions in the Programmer's Guide for getting to the anonymous CVS server. I'm running RedHat 6.1, and CVS 1.10 which What is CVS? An open-source network-transparent version control system. http://www.cvshome.org/ -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] failed assertion error on PG-7.0.2
Tom Lane [EMAIL PROTECTED] writes: Louis-David Mitterrand [EMAIL PROTECTED] writes: Fresh from /var/log/postgres.log: postgres localhost www-data auction SELECT: ../iconv/skeleton.c:297: gconv: Assertion `outbufstart == ((void *)0)' failed. ?? Anyone recognize that? A few seconds with glimpse shows that there is no file named skeleton.c, indeed no directory named iconv, in the current sources; much less any routine named gconv; nor any variable named outbufstart. So I'm pretty confused... glibc, related to i18n. -- Trond Eivind Glomsrød Red Hat, Inc.
