Re: [HACKERS] postgres dies while doing vacuum analyze

2001-06-16 Thread Trond Eivind Glomsrød
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

Re: [HACKERS] postgres dies while doing vacuum analyze

2001-06-16 Thread Tom Lane
[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

Re: [HACKERS] [PATCH] inet << indexability

2001-06-16 Thread Tom Lane
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 versi

Re: [HACKERS] Doing authentication in backend

2001-06-16 Thread Tom Lane
[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 authenti

Re: [HACKERS] postgres dies while doing vacuum analyze

2001-06-16 Thread Trond Eivind Glomsrød
Manuel Sugawara <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes: > > > 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 ra

Re: [HACKERS] [PATCH] inet << indexability

2001-06-16 Thread Tom Lane
Alex Pilosov <[EMAIL PROTECTED]> writes: > I didn't want to make them user-visible, however, the alternative, IMHO, > is worse, since these functions rely on network_broadcast and > network_network to do the work, calling sequence would be: > a) indxpath casts Datum to inet, passes to network_scan

Re: [HACKERS] postgres dies while doing vacuum analyze

2001-06-16 Thread Trond Eivind Glomsrød
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 i

Re: [HACKERS] [PATCH] inet << indexability (take 3)

2001-06-16 Thread Tom Lane
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 c

Re: [HACKERS] [PATCH] untrusted plperl

2001-06-16 Thread Tom Lane
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. On

Re: [HACKERS] Postgres

2001-06-16 Thread Tom Lane
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 syst