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
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Will do... what is the expected result of the testcase? Given a sufficiently large discrepancy between the string lengths, a core dump is the likely result. Try increasing the 16k numbers if it doesn't crash for you. Good work, Manuel! I'm surprised this hasn't been found before, because you'd think it'd be biting lots of people ... regards, tom lane ---(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] [PATCH] inet indexability
Alex Pilosov [EMAIL PROTECTED] writes: Also, I have a question: I put in a regression test to check that the type can be indexed, by doing 'explain select ...'. However, the expected result may vary when the optimizer is tweaked. Yes, I'd noted that already in looking at your prior version. I think it's best not to do an EXPLAIN in the regress test, because I don't want to have to touch the tests every time the cost functions are tweaked. However, we can certainly check to make sure that the results of an indexscan are what we expect. Is the table set up so that this is a useful test case? For example, it'd be nice to check boundary conditions (eg, try both and = on a case where they should give different results). Do you have any thought of making network_scan_first and network_scan_last user-visible functions? (Offhand I see no use for them to a user, but maybe you do.) If not, I'd suggest not using the fmgr call protocol for them, but just making them pass and return inet*, or possibly Datum. No need for the extra notational cruft of DirectFunctionCall. Another minor stylistic gripe is that you should use bool/true/false where appropriate, not int/1/0. Otherwise it looks pretty good. Oh, one more thing: those dynloader/openbsd.h and psql/tab-complete.c changes don't belong in this patch... regards, tom lane ---(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] Doing authentication in backend
[EMAIL PROTECTED] (Nathan Myers) writes: On Thu, Jun 14, 2001 at 01:42:26PM -0400, Tom Lane wrote: Also note that we could easily fix things so that the max-number-of- backends limit is not checked until we have passed the authentication procedure. A PM child that's still busy authenticating doesn't have to count. And impose a very short timeout on authentication. Yes. There's no time limit at present, but it will be easy to add one after we change to fork-before-authenticate (since each PM child can have its own itimer). This last could also be addressed (along with Solaris's Unix Sockets problem!) by changing the second argument to listen(2) from the current SOMAXCONN -- which is 5 in Solaris 2.7 -- to 127. See the six-page discussion in Stevens UNPv1 beginning at page 93. Unfortunately I only have Stevens' first edition, and it doesn't seem to have any such advice in it. Why is it a good idea to ignore the platform's specification of SOMAXCONN? Seems like on non-broken platforms, that would do more harm than good. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
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] [PATCH] inet indexability (take 3)
Alex Pilosov [EMAIL PROTECTED] writes: I think this addresses all Tom's concerns. Tom? :) Checked and applied ... regards, tom lane ---(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] [PATCH] untrusted plperl
Alex Pilosov [EMAIL PROTECTED] writes: Hope someone finds that useful and maybe even merged :) It looks great to me (except you forgot the documentation updates ;)). But it'd be nice to get a Perl expert to comment on the thing, particularly on the safe/unsafe-in-one-interpreter business. One thought that comes to mind: seems like it'd be possible to communicate via Perl global variables, functions, etc between safe and unsafe functions. This might be good, or it might be a vehicle for bypassing the safety restrictions. We should think hard about that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgres
Guru Prasad [EMAIL PROTECTED] writes: using postgres 7.1 version. Now the database got corrupted. I had no clue how it got corrupted. Basically, i did found that the data of various users existing (in /usr/local/pgsql/data directory). But there were no data existing in the following system catalogs. pg_database. (except template0 template1) pg_shadow. (except postgres user. Previously 15 users were there.) pg_tables. (Not showing any user created tables. Only system tables get displayed). But the data structure of individual tables exist somewhere. Suppose if i do 'select * from tablename' then field names gets displayed but says 'no rows'. At the same time, i am unable to get the structure through \d tablename. If there's no entry for your database in pg_database, how were you able to connect to do a 'select * from tablename'? I'd like to see exactly what you did and exactly what results you got, not your interpretations about whether there's data in tables or not. Whatever's going on here is probably more subtle than that. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
