Re: [HACKERS] All's quiet ... RC3 packaging ...
On Wed, Apr 04, 2001 at 10:56:27AM -0400, Tom Lane allegedly wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > On Wed, 4 Apr 2001, Tom Lane wrote: > >> I think we've got to remove that failing horology test before we wrap RC3. > > > can we comment out the test for now, so that its still in there, but not > > tested? or is there absolutely non way that we can fix that in the long > > term? > > Commenting it out was the only idea that I had. Maybe Thomas has a > better idea, though. Why not work with a maximum error in the regression tests? For instance, allow a small difference after the 8th digit? That would pick out the real bugs and let the round-off errors pass, right? Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configure problems on Solaris 2.7, pgsql 7.02 and 7.03
On Wed, Apr 04, 2001 at 06:46:12PM +0300, Martín Marqués allegedly wrote: > Why are you running configure inside src/? I'm not sure if the 7.0.x had the > configure on the src/ dir or the root. It's in the src dir with 7.0.x alright. > You could take a look at 7.1RC[2-3], which looks pretty stable, and I have > (RC1) compiled and working on a Solaris 8 SPARC. I'm using pgsql 7.0.3 on Solaris 7 Sparc and Solaris 8 Intel for a website that get's about 600,000 pageviews daily. pgsql 7.0.x works without problems for me and I'm connecting to it via JDBC. No crashes or major problems so far. Anyway, 7.0.x should work problem free on Solaris (there are some issues with 7.1 at the moment). To make this a bit easier to diagnose, could you send me the output of the following commands? | jumpstart:~$ uname -a | SunOS jumpstart 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-Enterprise | jumpstart:~$ echo $PATH | /sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/ccs/bin | jumpstart:~$ which sed | /bin/sed | jumpstart:~$ which gcc | /usr/local/bin/gcc | jumpstart:~$ gcc -v | Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs | gcc version 2.95.2 19991024 (release) | jumpstart:~$ which make | /usr/local/bin/make | jumpstart:~$ make -v | GNU Make version 3.78.1, by Richard Stallman and Roland McGrath. | Built for sparc-sun-solaris2.7 | Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 | Free Software Foundation, Inc. | This is free software; see the source for copying conditions. | There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A | PARTICULAR PURPOSE. | | Report bugs to <[EMAIL PROTECTED]>. It is of course possible that the output on your system is quite different. Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: RC3 ...
On Fri, Apr 06, 2001 at 09:23:35PM -0400, Bruce Momjian allegedly wrote: > > > Thomas, will you be doing .pdf files? I have had requests to put that > > > in the Debian documentation package. > > > > afaik, I don't have the means to generate pdf directly. Pointers would > > be appreciated, if there are mechanisms available on Linux boxes. > > > > We have had lots of offers of help for these conversions, so when the > > hardcopy is ready we can ask someone to convert from there. OK? > > Can you use ps2pdf to generate PDF? It is a utility that comes with > ghostscript. I know versions >= 6.0 are fine. PDF files generated from postscript with Adobe Acrobat are usually of much higher quality than those generated by ghostscript. It seems that ghostscript encodes rendered (bitmaps) documents, while Acrobat generates PDF files of a quality similar to the original postscript documents. You would definately have much hihger quality PDF files if someone with access to Acrobat would step forward. Too bad Acrobat is soo expensive :( Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Call for platforms (Solaris)
Hi I've been running RC3 regression tests, starting with a FreeBSD 4.2-STABLE and a Solaris 7 Sparc box. Both tests ran without any problems. I tried Solaris 8 Sparc next: it still suffered from the same unix socket problems. I had a look at the code and it seems to me that the use of unix sockets in RC3 is still enabled, even though it (appearently) doesn't work reliably on Solaris. Since it was rather strange that RC3 did work correctly on Solaris 7 but not 8, I also ran regression tests on another Solaris 7 and another 8 box, with the same results. Since I still didn't trust it, I also ran RC1 again on both Solaris 7 and 8; same result. And now things start getting weird. A little more than a week ago the RC1 regression tests ran with on average 10-15 tests randomly failing. Now, however, I can run the regression several times without any test failing. But if I run the regression test enough times (4-6 times), I do have tests that fail (about 2-5). The configuration of these servers hasn't changed in the last months and I used the same RC1 source and binaries. Can somebody confirm whether pgsql Solaris does or does not work correctly out-of-the-box? Disabling unix sockets will probably fix all these problems, so I'm naturally wondering whether unix socket will or will not be disabled in pgsql 7.1... Regards, Mathijs Ps. Vince, could you remove test results 46 and 47? I don't trust them anymore. -- "A book is a fragile creature. It suffers the wear of time, it fears rodents, the elements, clumsy hands." Umberto Eco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] pg_dump, formats & blobs
Hi
I've been experimenting with 7.1rc4 for a couple of hours. I was messing with
blobs, and the new toast setup worked quite nicely. One thing I especially
liked was the fact that by having pg_dump create a dumpfile in the custom or
tar format, I could also backup all blobs in one go.
Unfortunately, practice was a bit different. Which is why I would like to know
if these functions are intended for general use.
A small log:
sol2:~$ uname -srm
SunOS 5.8 sun4u
sol2:~$ createdb blaat
CREATE DATABASE
sol2:~$ psql -c 'create table test(a oid)' blaat
CREATE
sol2:~$ psql -c "insert into test values(lo_import('/etc/hosts'))" blaat
INSERT 18761 1
sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
sol2:~$ pg_restore -l blaat.bk
;
; Archive created at Sat Apr 14 01:03:02 2001
; dbname: blaat
; TOC Entries: 4
; Compression: -1
; Dump Version: 1.5-2
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 18749 TABLE test mathijs
3; 18749 TABLE DATA test mathijs
4; 0 BLOBS BLOBS
sol2:~$ grep serv /etc/hosts
10.1.8.12 serv2.ilse.nl
10.1.8.10 serv0.ilse.nl
sol2:~$ grep serv blaat.bk
sol2:~$ pg_dump -b -Ft -f blaat.tar blaat
zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat
sol2:~$ psql -c 'select version()' blaat
version
---
PostgreSQL 7.1rc4 on sparc-sun-solaris2.8, compiled by GCC 2.95.3
(1 row)
A backtrace reveals the following:
#0 0xff132e5c in strlen () from /usr/lib/libc.so.1
#1 0xff181890 in _doprnt () from /usr/lib/libc.so.1
#2 0xff183a04 in vsnprintf () from /usr/lib/libc.so.1
#3 0x2710c in ahprintf (AH=0x56cd0, fmt=0x430a8 "-- File: %s\n")
at pg_backup_archiver.c:1116
#4 0x2ee90 in _PrintExtraToc (AH=0x56cd0, te=0x5e838) at pg_backup_tar.c:305
#5 0x290e0 in _printTocEntry (AH=0x56cd0, te=0x5e838, ropt=0x681b0)
at pg_backup_archiver.c:1877
#6 0x25470 in RestoreArchive (AHX=0x56cd0, ropt=0x681b0)
at pg_backup_archiver.c:269
#7 0x2ffb8 in _CloseArchive (AH=0x56cd0) at pg_backup_tar.c:840
#8 0x24f68 in CloseArchive (AHX=0x56cd0) at pg_backup_archiver.c:136
#9 0x15128 in main (argc=6, argv=0xffbefcac) at pg_dump.c:1114
What happens is that in line 305 of pg_backup_tar.c, ahprintf is handed a NULL
pointer.
300 static void
301 _PrintExtraToc(ArchiveHandle *AH, TocEntry *te)
302 {
303 lclTocEntry *ctx = (lclTocEntry *) te->formatData;
304
305 ahprintf(AH, "-- File: %s\n", ctx->filename);
306 }
Could this be caused by the fact that IMHO blobs aren't dumped correctly?
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump, formats & blobs
On Sat, Apr 14, 2001 at 11:44:18AM +1000, Philip Warner allegedly wrote:
> At 01:14 14/04/01 +0200, Mathijs Brands wrote:
> ...
> >sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
> >sol2:~$ pg_restore -l blaat.bk
> ...
> >;
> >; Archive created at Sat Apr 14 01:03:02 2001
> ...
>
> This all looks fine.
Hmm, I can only agree.
sol2:~$ cksum postgresql-7.1rc4.tar.gz
615403298088934 postgresql-7.1rc4.tar.gz
sol2:~$ dropdb blaat
DROP DATABASE
sol2:~$ createdb blaat
CREATE DATABASE
sol2:~$ psql -c 'create table test(a oid)' blaat
CREATE
sol2:~$ psql -c "insert into test
values(lo_import('/export/home/mathijs/postgresql-7.1rc4.tar.gz'))" blaat
INSERT 22753 1
sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
sol2:~$ psql -c 'drop table test ; vacuum' blaat
VACUUM
sol2:~$ pg_restore -d blaat blaat.bk
sol2:~$ psql -c "select lo_export(test.a, '/export/home/mathijs/testfile') from test"
blaat
lo_export
---
1
(1 row)
sol2:~$ cksum testfile
61540329 8088934 testfile
sol2:~$ pg_restore -l blaat.bk
;
; Archive created at Sat Apr 14 03:59:02 2001
; dbname: blaat
; TOC Entries: 4
; Compression: -1
; Dump Version: 1.5-2
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 18792 TABLE test mathijs
3; 18792 TABLE DATA test mathijs
4; 0 BLOBS BLOBS
I couldn't get blobs to be restored correctly (must've been doing
something wrong). When something doesn't work, never question your
own methods ;)
> >sol2:~$ pg_dump -b -Ft -f blaat.tar blaat
> >zsh: segmentation fault (core dumped) pg_dump -b -Ft -f blaat.tar blaat
>
> This is less good. It's caused by the final part of TAR output, which also
> dumps a plain SQL script for reference (not actually ever used by
> pg_restore). I will fix this in CVS; ctx->filename is set to null for this
> script, and my compiler outputs '(null)', which is very forgiving of it.
It's more likely that your C library is more forgiving (ie. Open Source OS?).
> >Could this be caused by the fact that IMHO blobs aren't dumped correctly?
> >
>
> Is there some other problem with BLOBs that you did not mention? AFAICT,
> this is only a problem with TAR output (an will be fixed ASAP).
Yeah, they're not fool proof ;)
Sorry about the false alarm. I was convinced restoring blobs
didn't work correctly.
Regards,
Mathijs
--
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---(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] Solaris source code
On Mon, Jul 09, 2001 at 02:03:16PM -0700, Nathan Myers allegedly wrote: > On Mon, Jul 09, 2001 at 02:24:17PM +0200, Mathijs Brands wrote: > > On Thu, Jul 05, 2001 at 02:03:31PM -0700, Naomi Walker allegedly wrote: > > > At 04:30 PM 7/5/01 -0400, Bruce Momjian wrote: > > > >I have purchased the Solaris source code from Sun for $80. (I could > > > >have downloaded it for free after faxing them an 11 page contract, but I > > > >decided I wanted the CD's.) See the slashdot story at: > > > > > > > > http://slashdot.org/article.pl?sid=01/06/30/1224257&mode=thread > > > > > > > >My hope is that I can use the source code to help debug Solaris > > > >PostgreSQL problems. It includes source for the kernel and all user > > > >programs. The code is similar to *BSD kernels. It is basically Unix > > > >SvR4 with Sun's enhancements. It has both AT&T and Sun copyrights on > > > >the files. > > > > > > Bruce, > > > > > > We are about to roll out PostgreSQL on Solaris, and I am interested in any > > > Solaris specific gotcha's. Do you have some specifics in mind, or was this > > > just general preventive maintenance type steps? > > > > PostgreSQL 7.1 fails the regression tests when using a UNIX socket, > > which is faster than a TCP/IP socket (when both the client and the > > server are running on the same machine). > > Have you tried increasing the argument to listen in libpq/pgcomm.c > from SOMAXCONN to 1024? I think many people would be very interested > in your results. OK, I tried using 1024 (and later 128) instead of SOMAXCONN (defined to be 5 on Solaris) in src/backend/libpq/pqcomm.c and ran a few regression tests on two different Sparc boxes (Solaris 7 and 8). The regression test still fails, but for a different reason. The abstime test fails; not only on Solaris but also on FreeBSD (4.3-RELEASE). *** ./expected/abstime.out Thu May 3 21:00:37 2001 --- ./results/abstime.out Tue Jul 10 10:34:18 2001 *** *** 47,56 | Sun Jan 14 03:14:21 1973 PST | Mon May 01 00:30:30 1995 PDT | epoch - | current | -infinity | Sat May 10 23:59:12 1947 PST ! (6 rows) SELECT '' AS six, ABSTIME_TBL.* WHERE ABSTIME_TBL.f1 > abstime '-infinity'; --- 47,55 | Sun Jan 14 03:14:21 1973 PST | Mon May 01 00:30:30 1995 PDT | epoch | -infinity | Sat May 10 23:59:12 1947 PST ! (5 rows) SELECT '' AS six, ABSTIME_TBL.* WHERE ABSTIME_TBL.f1 > abstime '-infinity'; == I've checked the FreeBSD and Linux headers and they've got SOMAXCONN set to 128. Here's a snippet from the linux listen(2) manpage: BUGS If the socket is of type AF_INET, and the backlog argument is greater than the constant SOMAXCONN (128 in Linux 2.0 & 2.2), it is silently truncated to SOMAXCONN. Don't rely on this value in portable applications since BSD (and some BSD-derived systems) limit the backlog to 5. I've checked Solaris 2.6, 7 and 8 and the kernels have a default value of 128 for the number of backlog connections. This number can be increased to 1000 (maybe even larger). On Solaris 2.4 and 2.5 it is appearently set to 32. Judging from Adrian Cockcrofts Solaris tuning guide Sun has been using a default value of 128 from Solaris 2.5.1 on. You do need some patches for 2.5.1: patches 103582 & 103630 (SPARC) or patches 103581 & 10361 (X86). Later versions of Solaris don't need any patches. You can check (and set) the number of backlog connections by using the following command: Solaris 2.3, 2.4, 2.5 and unpatched 2.5.1: /usr/sbin/ndd /dev/tcp tcp_conn_req_max (untested) Solaris 2.5.1 (patched), 2.6, 7 and 8: /usr/sbin/ndd /dev/tcp tcp_conn_req_max_q It'd probably be a good idea to use a value of 128 for the number of backlog connections and not SOMAXCONN. If the requested number of backlog connections is bigger than the number the kernel allows, it should be truncated. Of course, there's no guarantee that this won't cause problems on arcane platforms such as Ultrix (if it is still supported). The Apache survival guide has more info on TCP/IP tuning for several platforms and includes information on the listen backlog. Cheers, Mathijs Ps. Just checking IRIX 6.5 - it's got the backlog set to 1000 connctions. -- And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold. The din of a million keyboards like unto a great storm shall cover the earth, and the followers of Mammon shall tremble. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Solaris source code
On Thu, Jul 05, 2001 at 04:30:40PM -0400, Bruce Momjian allegedly wrote: > I have purchased the Solaris source code from Sun for $80. (I could > have downloaded it for free after faxing them an 11 page contract, but I > decided I wanted the CD's.) See the slashdot story at: > > http://slashdot.org/article.pl?sid=01/06/30/1224257&mode=thread > > My hope is that I can use the source code to help debug Solaris > PostgreSQL problems. It includes source for the kernel and all user > programs. The code is similar to *BSD kernels. It is basically Unix > SvR4 with Sun's enhancements. It has both AT&T and Sun copyrights on > the files. Cool. It would be nice to know why the regression tests fail on Solaris when using a UNIX socket. Cheers, Mathijs ---(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] Solaris source code
On Thu, Jul 05, 2001 at 02:03:31PM -0700, Naomi Walker allegedly wrote: > At 04:30 PM 7/5/01 -0400, Bruce Momjian wrote: > >I have purchased the Solaris source code from Sun for $80. (I could > >have downloaded it for free after faxing them an 11 page contract, but I > >decided I wanted the CD's.) See the slashdot story at: > > > > http://slashdot.org/article.pl?sid=01/06/30/1224257&mode=thread > > > >My hope is that I can use the source code to help debug Solaris > >PostgreSQL problems. It includes source for the kernel and all user > >programs. The code is similar to *BSD kernels. It is basically Unix > >SvR4 with Sun's enhancements. It has both AT&T and Sun copyrights on > >the files. > > Bruce, > > We are about to roll out PostgreSQL on Solaris, and I am interested in any > Solaris specific gotcha's. Do you have some specifics in mind, or was this > just general preventive maintenance type steps? PostgreSQL 7.1 fails the regression tests when using a UNIX socket, which is faster than a TCP/IP socket (when both the client and the server are running on the same machine). We're running a few small PostgreSQL databases on Solaris and we're going to implement a bigger one in the near future. If you connect via TCP/IP sockets, you should be safe. We're using JDBC to connect to the database and JDBC always uses a TCP/IP socket. So far we haven't run into any real problems, although PostgreSQL did crash once, for unknown reasons (probably becase someone was messing with it). Not really helpful, I guess. Doing some testing of your own is highly recommended ;) Cheers, Mathijs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MS interview
On Wed, Aug 15, 2001 at 10:39:24AM +0200, John Anderson allegedly wrote: > AFAIK, OLAP backends essentially provide a cache of denormalised data > that provide fast access (no need to re-run complex queries) to large > data sets, and a set of aggregate functions to analyse the data. > > There's also a language called MDX that goes with it, but I haven't > worked with that. MDX is the query language used for querying cubes of data in an multi dimensional database. MDX is usually automatically generated, as it is far more complex than SQL. Cheers, Mathijs -- Beauty and music seduce us first... Later, ashamed of our own sensuality, we insist on meaning. -- Clive Barker ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: [SQL] PostgreSQL crashes on me :(
Hello all, I would like to thank Tom, Ian and the other pgsql wizards for their prompt response. This must surely be open source at it's best :) I've worked around the situation by running a small script that continually monitors postgres and takes appropriate action if postgres shuts down. I'm assuming this problem won't lead to any data corruption. Mathijs -- "Borrowers of books -- those mutilators of collections, spoilers of the symmetry of shelves, and creators of odd volumes." Charles Lamb (1775-1834)
Re: [SQL] Re: [HACKERS] why the DB file size does not reduce when 'delete'the data in DB?
On Sun, Mar 04, 2001 at 10:01:37AM +0800, xuyifeng allegedly wrote: > - Original Message - > From: The Hermit Hacker <[EMAIL PROTECTED]> > To: Jaruwan Laongmal <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, March 02, 2001 8:04 PM > Subject: Re: [HACKERS] why the DB file size does not reduce when 'delete'the data in >DB? > > > On Fri, 2 Mar 2001, Jaruwan Laongmal wrote: > > > > > I had deleted a very large number of records out of my SQL table in order to > > > decrease the harddisk space. But after I use command 'ls -l > > > /usr/local/pgsql/data/base/', it is found that the size of concerning files > > > do not reduce due to the effect of 'delete' SQL command. What should I do > > > if I would like to decrease the harddisk space? > > > > VACUUM > > could anyone remove this nasty bug in 7.2? this is already a big pain and is the >reason > why am I still using MySQL in my product server. another nasty thing is it does not > allow me to reference table in another database. sigh. Why would this be a bug? Sure, maybe it's not what you expected, but I hardly think it qualifies as a bug. For instance, Oracle doesn't release storage (datafiles specifically) after it has allocated space for them. In fact, I wish I could force pgsql to allocate storage it might need in the future. It would be great if I could force pgsql to allocated four datafiles spread across four harddisks, so I would enjoy a) better database performance and b) rest assured I have the diskspace when I need it in the future. Call it a poor mans RAID; I think MySQL can perform this trick. If pgsql can do this, please let me know But back to your problem. One way to get the amount of space allocated to shrink is by recreating the database. Dump it using pg_dump and recreate it using the backup you just made. This is a fairly simple and quick process. Give it a try on a small test database first; you don't want to risk loosing your data. Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Hi Is there a list somewhere listing the platforms 7.1 is being tested on right now? I'd be able to run regression tests on the following platforms, if necessary: FreeBSD 3.3 (x86) FreeBSD 4.2 (x86) Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) Solaris 7 (SPARC) Solaris 8 (x86) Solaris 8 (SPARC) IRIX 6.2 IRIX 6.5 If I can get the box back to working order, Alpha Linux is also an option. I'd be willing to build binary packages for Solaris and IRIX. Regards, Mathijs -- "Books constitute capital." Thomas Jefferson ---(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
On Mon, Mar 26, 2001 at 05:41:31PM -0500, Vince Vielhaber allegedly wrote: > On Tue, 27 Mar 2001, Mathijs Brands wrote: > > Hi > > > > Is there a list somewhere listing the platforms 7.1 is being > > tested on right now? I'd be able to run regression tests on > > the following platforms, if necessary: > > > > FreeBSD 3.3 (x86) > > FreeBSD 4.2 (x86) > > Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) > > Solaris 7 (SPARC) > > Solaris 8 (x86) > > Solaris 8 (SPARC) > > IRIX 6.2 > > IRIX 6.5 > > > > If I can get the box back to working order, Alpha Linux is > > also an option. I'd be willing to build binary packages for > > Solaris and IRIX. > > Check out the Developer's Corner on the website. It's at the > top of the page. > > Vince. I had a look at it, but that surely can't be the complete list. There are only 20 results listed... Mathijs -- "Where is human nature so weak as in a bookstore!" Henry Ward Beecher (1813-1887) ---(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
On Mon, Mar 26, 2001 at 06:35:59PM -0500, Tom Lane allegedly wrote: > Thomas Lockhart <[EMAIL PROTECTED]> writes: > >> Anyway, the last CVS update to port/ultrix.h that appears to have come > >> from someone actually using Ultrix was rev 1.2 on 7-May-97, which > >> predates the very existence of s_lock.h as a separate file. So I'd > >> definitely advise Alexander to find a tarball from that era and look at > >> how Ultrix was handled then. > >> I dunno if we even have tarballs from that far back on-line ... I > >> suppose another possibility is a date-based pull from the CVS server. > > > What can we help with Alex? > > After digging around in the old code I have to retract my opinion that > a test-and-set implementation used to exist for MIPS. The code did > have SysV-semaphore-based support for machines without test-and-set, > and undoubtedly that's what was used on the old Ultrix port. (The > non-test-and-set code was broken for awhile, but I'd forgotten that > it formerly worked.) > > The non-test-and-set case should work again in current CVS, and I'd > appreciate it if Alexander would verify that. But as far as getting > some test-and-set support for MIPS goes, it looks like the only way > is for someone to sit down with a MIPS assembly manual. I haven't > got one, nor access to a machine to test on... I've got access to an Indigo² (IRIX 6.5, MIPS R1), another Indigo² (IRIX 6.2, MIPS R4400) and a DECStation (NetBSD 1.?, MIPS R3000). The DECStation (also known as PMAX) originally ran Ultrix. If anybody has some code that needs testing, I'd be more than willing. However, if test-and-set works anything like I imagine, we really need to test it on a multi-cpu MIPS machine. A good starting point might be the test-and-set code in the NetBSD and Linux MIPS kernels. Btw. Everything you never wanted to know about the MIPS architecture: http://www.mips.com/Documentation/ Cheers, Mathijs -- "A book is a fragile creature. It suffers the wear of time, it fears rodents, the elements, clumsy hands." Umberto Eco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
On Tue, Mar 27, 2001 at 12:01:24PM +1000, Justin Clift allegedly wrote: > I know that Sourceforge has been adding all sorts of machines to their > compile farm. > > Maybe it would be worthwhile taking a look if they have platforms we > don't? > > Regards and best wishes, > > Justin Clift Compaq also still hands out free test accounts on Digital servers running Linux, Tru64 and FreeBSD... I think it's called the Testdrive program. Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: [HACKERS] Re: Call for platforms)
On Mon, Mar 26, 2001 at 07:09:38PM -0500, Tom Lane allegedly wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > That is not already available from the Irix support code?
>
> What we have for IRIX is
>
> #if defined(__sgi)
> /*
> * SGI IRIX 5
> * slock_t is defined as a unsigned long. We use the standard SGI
> * mutex API.
> *
> * The following comment is left for historical reasons, but is probably
> * not a good idea since the mutex ABI is supported.
> *
> * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
> * assembly from his NECEWS SVR4 port, but we probably ought to retain this
> * for the R3000 chips out there.
> */
> #include "mutex.h"
> #define TAS(lock) (test_and_set(lock,1))
> #define S_UNLOCK(lock)(test_then_and(lock,0))
> #define S_INIT_LOCK(lock) (test_then_and(lock,0))
> #define S_LOCK_FREE(lock) (test_then_add(lock,0) == 0)
> #endif /* __sgi */
>
> Doesn't look to me like it's likely to work on anything but IRIX ...
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2.
Appearently gcc chokes on some assembly in src/backend/storage/buffer/s_lock.c
(tas_dummy on line 235 to be precise).
Here's the offending code:
#if defined(__mips__)
static void
tas_dummy()
{
__asm__ _volatile__(
"\
.global tas \n\
tas:\n\
.frame $sp, 0, $31 \n\
ll $14, 0($4) \n\
or $15, $14, 1 \n\
sc $15, 0($4) \n\
beq $15, 0, fail\n\
bne $14, 0, fail\n\
li $2, 0 \n\
.livereg 0x2000FF0E,0x0FFF \n\
j $31 \n\
fail: \n\
li $2, 1 \n\
j $31 \n\
");
}
Notice the single underscore before volatile. I just checked the CVS
version of s_lock.c and this is still not fixed. Fixing this causes
as (the SGI version, not GNU as) to choke on the '.global tas' statement.
s_lock.c: At top level:
s_lock.c:234: warning: `tas_dummy' defined but not used
as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global
.global tas
gmake[4]: *** [s_lock.o] Error 1
Commenting out the .global statements does produce a binary, but it can't
complete the regression test due to other problems.
IpcSemaphoreCreate: semctl(id=0, 0, SETALL, ...) failed: Bad address
I'll see if I can come up with a solution for the .global and the
semaphore problem. I'll check wether pgsql 7.0 does run on this box too.
One wonders how Robert Bruccoleri did get 7.1RC1 to work properly. I'll
check the archive for clues.
On my FreeBSD 4.2 box 7.1RC1 runs flawlessly. I've also tested the CVS
version a few days ago on a 4.1.1 box without any problems.
FreeBSD 3.3 however does have some problems.
*** ./expected/float8-small-is-zero.out Fri Mar 31 07:30:31 2000
--- ./results/float8.out Tue Mar 27 02:28:07 2001
***
*** 214,220
SET f1 = FLOAT8_TBL.f1 * '-1'
WHERE FLOAT8_TBL.f1 > '0.0';
SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR: Bad float8 input format -- overflow
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
ERROR: pow() result is out of range
SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
--- 214,220
SET f1 = FLOAT8_TBL.f1 * '-1'
WHERE FLOAT8_TBL.f1 > '0.0';
SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR: floating point exception! The last floating point operation either exceeded
legal ranges or was a divide by zero
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
ERROR: pow() result is out of range
SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
Some geometry tests also fail. I'll check those tomorrow, erm, today. The
same goes for 7.1RC1 on Solaris 8 (Intel and Sparc).
Cheers,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
On Tue, Mar 27, 2001 at 06:36:37AM -0500, D'Arcy J.M. Cain allegedly wrote: > Thus spake Tom Ivar Helbekkmo > > > We need some NetBSD folks to speak up! > > I have successfully compiled it from CVS sources on my NetBSD -current but > I can't find the tar file for RC1 to try it with the package system. Can > someone point me to it please. It's probably in /pub/dev (or something similar) on the ftp server... Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Spinlocks on SGI's
On Tue, Mar 27, 2001 at 08:59:45AM -0500, Robert E. Bruccoleri allegedly wrote: > I contributed the first working s_lock.c code for the SGI's over three > years ago (using the test_and_set library calls). It's been working > for me ever since in a heavy multi-user environment. Please don't > change it unless there's an overwhelming reason. > > Also, the GNU compiler systems works poorly on SGI's. In this > environment, you need to stick to the SGI provided compilers. Once you > get used to them, they work fairly well. The problem is that SGI wants a couple of hundred dollars for it :( Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
On Tue, Mar 27, 2001 at 09:57:45AM -0500, Bruce Momjian allegedly wrote: > We just fixed that yesterday. Can you grab the most recent CVS and give > it a try? Even if you fix this it won't work (I tried it). Robert mailed why. Check the URL below for more information. It crashes on semctl :( http://freeware.sgi.com/shared/howto.html#b1 Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Solaris problems (was Re: [HACKERS] SPARC Solaris 8 OK)
On Tue, Mar 27, 2001 at 10:34:13AM -0600, Brian P Millett allegedly wrote: > == > All 76 tests passed. > == > > vlad: uname -a > SunOS vlad 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-5_10 > > Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs > gcc version 2.95.2 19991024 (release) > > CFLAGS=-O6 -mcpu=v8 -Wa,-xarch=v8plusa > CXXFLAGS=-O6 -felide-constructors -fno-exceptions -fno-rtti -mcpu=v8 >-Wa,-xarch=v8plusa > > configure --prefix=/opt/pgsql \ >--with-tcl \ >--with-includes=/opt/sfw/include \ >--with-libraries=/opt/sfw/lib \ >--with-tclconfig=/opt/sfw/lib \ >--with-CC=gcc \ >--with-CXX=gcc > > This was cvs checjout this am (3/27/2001) > > Thanks. Erm, I've just tested 7.1RC1 on Solaris 8 x86 and SPARC. Solaris x86 works without any problems and passes the regression test (apart from a few very small roundoff errors in the geometry tests). However, on Solaris SPARC tests randomly fail (like someone else reported too). I've tried running configure without any options and the options given above, but the results were the same. I'm using gcc 2.95.3. I'll see if I can give the cvs version and gcc 2.95.2 a try tomorrow. Same goes for Solaris 7 SPARC and maybe Solaris 2.6 SPARC. Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [BUGS] Tests randomly failed
On Tue, Mar 27, 2001 at 07:17:47PM +0200, Peter Eisentraut allegedly wrote:
> Tom Lane writes:
>
> > Alexander Klimov <[EMAIL PROTECTED]> writes:
> > > Yes, it was really just incidence -- I try again, and 15 of 15 `make
> > > check' passed with TCP sockets, but only 3 of 15 passed with UNIX
> > > sockets. So, final decision is `Unix sockets are not relaible on Solaris'
>
> What become up 'set maxuprc=256'? I thought that made it work. Could
> other people try it or has it been disproven?
I'm giving this a test now...
Cheers,
Mathijs
--
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Solaris 7 SPARC passes tests (was Re: [HACKERS] Re: [BUGS] Tests randomly failed)
On Wed, Mar 28, 2001 at 02:40:00AM +0200, Mathijs Brands allegedly wrote: > On Tue, Mar 27, 2001 at 07:17:47PM +0200, Peter Eisentraut allegedly wrote: > > Tom Lane writes: > > > > > Alexander Klimov <[EMAIL PROTECTED]> writes: > > > > Yes, it was really just incidence -- I try again, and 15 of 15 `make > > > > check' passed with TCP sockets, but only 3 of 15 passed with UNIX > > > > sockets. So, final decision is `Unix sockets are not relaible on Solaris' > > > > What become up 'set maxuprc=256'? I thought that made it work. Could > > other people try it or has it been disproven? > > I'm giving this a test now... No luck :( Tests still randomly crash. (This is an Ultra 10 machine.) 7.1RC1 on Solaris 7 SPARC does pass the regression tests (apart from the random test, which seems to be ignored on Solaris). (This is an Ultra 420 machine.) Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(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] Spinlocks on SGI's
On Tue, Mar 27, 2001 at 11:06:20AM -0400, The Hermit Hacker allegedly wrote: > On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote: > > Dear Marc, > > > On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote: > > > > > > > I contributed the first working s_lock.c code for the SGI's over three > > > > years ago (using the test_and_set library calls). It's been working > > > > for me ever since in a heavy multi-user environment. Please don't > > > > change it unless there's an overwhelming reason. > > > > > > > > Also, the GNU compiler systems works poorly on SGI's. In this > > > > environment, you need to stick to the SGI provided compilers. Once you > > > > get used to them, they work fairly well. > > > > > > Robert, any possibility of getting pre-compiled binaries for SGI that we > > > can put up on the site? For those that can't afford the extra cost of the > > > compilers? :) > > > > Yes. What exactly do you need from the Postgresql tree after a successful > > compilation and test? > > easiest, I think, unless SGI has a special packaging (pkg_add) format, is > a tar of /usr/local/pgsql ... that *should* have everything required ... > bin, libs and includes ... > > if you could create one based on RC1 and upload that, then we can get some > testing on whether or not that works before the release? Wouldn't it be best to build IRIX 6.2 binaries? Those should run properly on IRIX 6.2 and anything newer. Of course, having both IRIX 6.2 and 6.5 binaries wouldn't really hurt... Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris
On Wed, Mar 28, 2001 at 06:48:27PM -0500, Tom Lane allegedly wrote: > Mathijs Brands <[EMAIL PROTECTED]> writes: > > PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked. > > Hm. But 7.1 postgres backends fail to change their ps display? > Does sendmail change its ps display on your machine? template1=# \set VERSION = 'PostgreSQL 7.0.3 on sparc-sun-solaris2.7, compiled by gcc 2.95.2' DBNAME = 'template1' USER = 'mathijs' PORT = '5432' ENCODING = 'SQL_ASCII' PROMPT1 = '%/%R%# ' PROMPT2 = '%/%R%# ' PROMPT3 = '>> ' HISTSIZE = '500' template1=# [1]+ Stopped psql template1 jumpstart.l3.ilse.nl:/export/home/mathijs >/usr/ucb/ps auxww|grep post mathijs297 0.1 0.2 6120 3352 pts/1S 01:59:18 0:00 /opt/pgsql/bin/./postgres mathijs localhost template1 idle mathijs319 0.1 0.1 944 696 pts/3S 01:59:45 0:00 grep post mathijs 25810 0.0 0.1 5736 2160 pts/1S 20:44:34 0:00 /opt/pgsql/bin/./postmaster template1=# \set VERSION = 'PostgreSQL 7.1RC1 on sparc-sun-solaris2.8, compiled by GCC 2.95.3' DBNAME = 'template1' USER = 'mathijs' PORT = '5432' ENCODING = 'SQL_ASCII' PROMPT1 = '%/%R%# ' PROMPT2 = '%/%R%# ' PROMPT3 = '>> ' template1=# ^Z[1] + Stopped (SIGTSTP)psql template1 $ /usr/ucb/ps auxww|grep post mathijs 8072 0.1 1.4 5552 3352 pts/2S 01:01:43 0:00 ./postmaster -D /export/home/mathijs/pgtest/data mathijs 8074 0.1 0.3 976 672 pts/2S 01:01:55 0:00 grep post mathijs 8067 0.1 0.8 4912 1984 pts/2S 01:01:37 0:00 ./postmaster -D /export/home/mathijs/pgtest/data I guess it doesn't work :( Of course, it's also possible it doesn't work on Solaris 8, but does on 7. I'll check this and if this is the case, I'll post it. Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(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: [PORTS] pgmonitor and Solaris
On Wed, Mar 28, 2001 at 07:12:39PM -0500, Tom Lane allegedly wrote: > Mathijs Brands <[EMAIL PROTECTED]> writes: > > mathijs297 0.1 0.2 6120 3352 pts/1S 01:59:18 0:00 >/opt/pgsql/bin/./postgres mathijs localhost template1 idle > > The interesting point about this is that the 7.0.3-on-2.7 installation > *is* managing to change its PS display. So either Solaris 2.8 > retrogressed (different predefined symbols maybe?), or we broke the code > since 7.0.3. > > Anyway I think the right thing to look at is why the 7.1 install is not > managing to update the display. > > regards, tom lane Here's 7.1: template1=# \set VERSION = 'PostgreSQL 7.1RC1 on sparc-sun-solaris2.7, compiled by GCC 2.8.1' DBNAME = 'template1' USER = 'mathijs' PORT = '5432' ENCODING = 'SQL_ASCII' PROMPT1 = '%/%R%# ' PROMPT2 = '%/%R%# ' PROMPT3 = '>> ' template1=# ^Z [1]+ Stopped ./psql template1 ilsedb:~/pgtest/bin$ /usr/ucb/ps auxww|grep post mathijs 29830 0.1 0.2 6328 3976 pts/4S 02:18:16 0:00 ./postmaster -D /export/home/mathijs/pgtest/data mathijs 29832 0.1 0.1 960 704 pts/4S 02:18:28 0:00 grep post mathijs 29823 0.0 0.1 5696 2176 pts/4S 02:18:03 0:00 ./postmaster -D /export/home/mathijs/pgtest/data No go... Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris
On Wed, Mar 28, 2001 at 04:56:15PM -0500, Bruce Momjian allegedly wrote: > [ Charset ISO-8859-1 unsupported, converting... ] > > whats wrong with /usr/ucb/ps auxw | grep $PGUSER > > > > to get only the processes for PG? > > I can do that if there is no other option, but on my BSDI machine, > restricting ps to a specific user is much faster than a ps on the whole > system. Seeing that 'ps' is run by default every 5 seconds, this could > be a performance issue. > > If I have to use 'grep' I will, but I was hoping for a real user > restriction. How about the following: ilsefe2:~$ /usr/ucb/ps -aux|head -1 USER PID %CPU %MEM SZ RSS TT SSTART TIME COMMAND Broken Pipe ilsefe2:~$ /usr/ucb/ps -aux|grep mathijs mathijs 7255 0.1 0.2 2432 1816 pts/0S 00:12:41 0:00 -bash mathijs 7775 0.1 0.1 960 728 pts/0S 00:24:29 0:00 grep mathijs mathijs 7344 0.0 0.1 1064 912 pts/0T 00:14:56 0:00 man ps mathijs 7359 0.0 0.1 1040 808 pts/0T 00:14:57 0:00 sh -c more -s /tmp mathijs 7360 0.0 0.1 1184 968 pts/0T 00:14:57 0:00 more -s /tmp/mp3Ha ilsefe2:~$ ps -U mathijs -o user,pid,pcpu,pmem,vsz,rss,tty,s,stime=START -o time,comm USER PID %CPU %MEM VSZ RSS TT SSTARTTIME COMMAND mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:570:00 sh mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:410:00 -bash root 7816 0.1 0.1 1080 840 pts/0 O 00:28:130:00 ps mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:560:00 man mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:570:00 more It doesn't use any extra extra programs, nor the somewhat deprecated /usr/ucb/ps command. The only problem I see may be the alignment of some fields. The ps command itself is listed because the user mathijs was running it... Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris
On Thu, Mar 29, 2001 at 12:30:06AM +0200, Mathijs Brands allegedly wrote: > On Wed, Mar 28, 2001 at 04:56:15PM -0500, Bruce Momjian allegedly wrote: > > [ Charset ISO-8859-1 unsupported, converting... ] > > > whats wrong with /usr/ucb/ps auxw | grep $PGUSER > > > > > > to get only the processes for PG? > > > > I can do that if there is no other option, but on my BSDI machine, > > restricting ps to a specific user is much faster than a ps on the whole > > system. Seeing that 'ps' is run by default every 5 seconds, this could > > be a performance issue. > > > > If I have to use 'grep' I will, but I was hoping for a real user > > restriction. > > How about the following: > > ilsefe2:~$ /usr/ucb/ps -aux|head -1 > USER PID %CPU %MEM SZ RSS TT SSTART TIME COMMAND > Broken Pipe > ilsefe2:~$ /usr/ucb/ps -aux|grep mathijs > mathijs 7255 0.1 0.2 2432 1816 pts/0S 00:12:41 0:00 -bash > mathijs 7775 0.1 0.1 960 728 pts/0S 00:24:29 0:00 grep mathijs > mathijs 7344 0.0 0.1 1064 912 pts/0T 00:14:56 0:00 man ps > mathijs 7359 0.0 0.1 1040 808 pts/0T 00:14:57 0:00 sh -c more -s /tmp > mathijs 7360 0.0 0.1 1184 968 pts/0T 00:14:57 0:00 more -s /tmp/mp3Ha > ilsefe2:~$ ps -U mathijs -o user,pid,pcpu,pmem,vsz,rss,tty,s,stime=START -o time,comm > USER PID %CPU %MEM VSZ RSS TT SSTARTTIME COMMAND > mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:570:00 sh > mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:410:00 -bash > root 7816 0.1 0.1 1080 840 pts/0 O 00:28:130:00 ps > mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:560:00 man > mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:570:00 more Damn! Small correction: ps -U mathijs -o user,pid,pcpu,pmem,vsz=SZ -o rss,tty,s,stime=START -o time,comm Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Re: [PORTS] pgmonitor and Solaris
On Fri, Mar 30, 2001 at 11:07:25AM +0100, Pete Forman allegedly wrote: > I've done a quick survey of the Suns available to me to see whether > sendmail updates the ps display. The summary is: > >1) Require "/usr/ucb/ps w" at least. /usr/bin/ps has no options > that I can find to display the status of sendmail. > >2) Older versions of sendmail do not update the status. 8.6 does > not update, 8.8.8 does. > >3) Solaris 2.5 and 2.5.1 have sendmail 8.6, 7 has 8.9.1, 8 has > 8.9.3. Some 2.6 have 8.6, others have 8.8.8. Presumably > patches have beed applied. > > On other OSs, AIX 4.1, 4.2, 4.3 have sendmail 8.8.4, 8.8.6, 8.8.8 or > 8.9.3. They all display the status in both SysV and BSD modes. > On AIX there is one ps command which handles both styles. > > IRIX 6.2 and 6.5.4m through 6.5.10m have sendmail 8.8.8, 8.9.1, 8.9.3. > No status is available. There do not appear to be any BSD-ish ps > options. The way /usr/ucb/ps in Solaris extracts the status for a process requires root rights and is (in my opinion) pretty gross. What it does is read the pseudo-file /proc//psinfo, which contains the real parameters supplied to the program and not the clobbered version. Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(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] Third call for platform testing
On Fri, Mar 30, 2001 at 03:17:06PM +, Thomas Lockhart allegedly wrote: > And here are the up-to-date platforms; thanks for the reports: > Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier Marc, was this done without unix sockets? Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Third call for platform testing (linux 2.4.x)
On Sat, Mar 31, 2001 at 12:02:35PM +1200, Franck Martin allegedly wrote: > I still don't see an entry for Linux 2.4.x > > Cheers. This should fix that: == All 76 tests passed. == rm regress.o make[2]: Leaving directory `/usr/exp/tmp/postgresql-7.1RC1/src/test/regress' make[1]: Leaving directory `/usr/exp/tmp/postgresql-7.1RC1/src/test' pc11j:/usr/exp/tmp/postgresql-7.1RC1$ uname -a Linux pc11j 2.4.2 #8 Fri Mar 2 16:40:13 CET 2001 i686 unknown Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Encoding conversions in psql
Howdy,
Can anyone explain to me when psql tries to convert between encodings?
It seems to disregard encodings set with SET CLIENT_ENCODING.
The following reproduces the behaviour I'm seeing:
1. create an UNICODE database
2. run the following:
set client_encoding to latin1;
create table bla(a text);
insert into bla values('meëep');
3. try the following from psql:
Welcome to psql 7.3.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
mathijs=# select * from bla;
a
---
meëep
(1 row)
mathijs=# set client_encoding = latin1;
SET
mathijs=# select * from bla;
a
--
meep
(1 row)
mathijs=# \encoding latin1
mathijs=# select * from bla;
a
---
meëep
(1 row)
After setting CLIENT_ENCODING, the middle character gets dropped. To me
it seems like psql is considering the data it gets from the server as
UTF8, tries to interpret it as UTF8, sees the ë (which is indeed an
invalid UTF8 character) and drops it.
My question is: why does psql seem to think it's receiving UTF8 data
-after- I've changed the client_encoding. I've checked with a network
sniffer that results returned with or without using \encoding (as
expected) are the same. Is this behaviour a bug? If not, it does not
seem very obvious to me; I would expect psql to keep track of the
encoding set between the server and the client.
Cheers,
Mathijs
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
