> Tom Lane wrote:
> > Well, we're not doing that; and I see no good reason to make the thing
> > be a builtin function at all. Since it's just an example, it can very
> > well be a contrib item with a creation script. Probably *should* be,
> > in fact, because dynamically created functions are w
Further digging: the backtrace from the SIGSEGV looks like
#0 0xc00a02fc in ?? () from /usr/lib/libc.1
malloc + 1132
#1 0xc267cbb4 in ?? ()
Perl_sv_grow + 244
from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl
#2 0xc26815b0 in ?? ()
Perl_sv_setpv + 312
from
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> On HPUX 10.20, using perl 5.6.1, plperl builds without complaint but
>> SIGSEGV's upon use. AFAIR this worked last time I tried it; any idea
>> what you might have changed?
> I have written it so that the commands that are execut
NunoACHenriques <[EMAIL PROTECTED]> writes:
> On Sun, 9 Jun 2002, Tom Lane wrote:
>> Is the data in the tables changing constantly?
> Not constantly, once a day.
Can't you set up a situation where the failure is reproducible, then?
On a day where you get the failure, dump the database and
Hi!
On Sun, 9 Jun 2002, Tom Lane wrote:
>Is the data in the tables changing constantly? If you can repeat the
>same query on the same data and get varying results, then we're
>dealing with something odder than I suspected.
>
> regards, tom lane
>
Not const
NunoACHenriques <[EMAIL PROTECTED]> writes:
> I should say that this error is a non-deterministic one. It happened
> once/twenty...
Is the data in the tables changing constantly? If you can repeat the
same query on the same data and get varying results, then we're
dealing with something o
Hi!
I should say that this error is a non-deterministic one. It happened
once/twenty...
---explain info-
spid=> explain insert into warehouse_tmp (uri, expression, n, relevance, spid_measure,
size, title, sample)
spid-
NunoACHenriques <[EMAIL PROTECTED]> writes:
> Jun 2 06:29:37 srv31 postgres[2986]: [57279] ERROR: tuplesort: unexpected end of
>data
Hmm. This is an internal consistency check in the sort code. Perhaps
you've found a bug, but there's not enough info here to do much. Can
you provide the EXPL
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Agreed on all accounts ... which is why this time, I want to do a proper
> branch when beta starts ... hell, from what I've seen suggested here so
> far, we have no choice ... At least then we can 'rip out' something from
> the beta tree without hav
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Yeah. I'd love to have somebody explain this to me. I noticed when
> zinc was mentioned, but I don't know *what* it is. Care to send me a
> link?
I think http://www.twinsun.com/tz/tz-link.htm is the underlying timezone
database that Thomas is referri
On Sun, 9 Jun 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I *really* wish ppl would stop harping on the length of the last beta
> > cycle ... I will always rather delay a release due to an *known*
> > outstanding bug, especially one that just needs a little bit more
Joe Conway <[EMAIL PROTECTED]> writes:
> Returning GUC variable "SHOW ALL" results as a query result has been
> discussed before, and I thought there was agreement that it was a
> desirable backend feature.
So it is, but I had expected it to be implemented by changing the
behavior of SHOW, same
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 08 June 2002 22:48
> To: Peter Eisentraut
> Cc: PostgreSQL-development
> Subject: Re: Roadmap for a Win32 port
>
>
> >
> > > Also, it seems Win32 doesn't need these scripts, except initdb.
> >
> > The util
13 matches
Mail list logo
