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
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
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
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
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
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
[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
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
[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
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
10 matches
Mail list logo
