On Sun, 22 Oct 2000, Bruce Momjian wrote:
> > Palle Girgensohn <[EMAIL PROTECTED]> writes:
> > > GNU gdb 4.18
> > > Program terminated with signal 11, Segmentation fault.
> > > (gdb) bt
> > > #0 0x8136eb2 in GetTemplateEncoding ()
> > > #1 0x8136d66 in pg_mb2wchar_with_len ()
> > > #2 0x8
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I do not believe this backtrace. textlike does not call int8_text;
>
> > Only Tom Lane could question a backtrace and get away with it. :-)
>
> If you haven't ever seen a bogus backtrace, you've not been using
> debuggers long enough ;-). gdb h
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I do not believe this backtrace. textlike does not call int8_text;
> Only Tom Lane could question a backtrace and get away with it. :-)
If you haven't ever seen a bogus backtrace, you've not been using
debuggers long enough ;-). gdb has no good way
> Palle Girgensohn <[EMAIL PROTECTED]> writes:
> > GNU gdb 4.18
> > Program terminated with signal 11, Segmentation fault.
> > (gdb) bt
> > #0 0x8136eb2 in GetTemplateEncoding ()
> > #1 0x8136d66 in pg_mb2wchar_with_len ()
> > #2 0x810adab in int8_text ()
> > #3 0x810ae82 in textlike ()
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> I was surprised that there was funcion names, since there shouldn't be
> any (no debugging symbols).
Not necessarily. If you haven't applied strip(1) to the executable,
there will be function names in the backtrace on most platforms, even
without -g
Tom Lane <[EMAIL PROTECTED]> writes:
> and GetTemplateEncoding is just about as SEGV-proof as any routine
> I've ever seen:
>
> static inttemplateEncoding;
> ...
> int
> GetTemplateEncoding()
> {
> return (templateEncoding);
> }
Heh
> I speculate that you gave gdb the wrong executabl
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> GNU gdb 4.18
> Program terminated with signal 11, Segmentation fault.
> (gdb) bt
> #0 0x8136eb2 in GetTemplateEncoding ()
> #1 0x8136d66 in pg_mb2wchar_with_len ()
> #2 0x810adab in int8_text ()
> #3 0x810ae82 in textlike ()
> #4 0x812ef14
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> I cannot reproduce this error on a fresh
> installation on another machine, which puzzles me. I though it might
> have to do with the the database beeing dumped/restored to this new
> installation, but I found no way to get the data there without
> du
Hi!
Here's a traceback from the time it failed, unfortunately without
debugging symbols. I cannot reproduce this error on a fresh
installation on another machine, which puzzles me. I though it might
have to do with the the database beeing dumped/restored to this new
installation, but I found no w
Tom Lane <[EMAIL PROTECTED]> writes:
> Palle Girgensohn <[EMAIL PROTECTED]> writes:
> Oh, gee. sorry! I slipped with the mouse when cut'n'pasting. The
> first > statement should be a create view. The view is dropped and
> created > "on-the-fly" with different where-clauses every time,
> dependin
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> Oh, gee. sorry! I slipped with the mouse when cut'n'pasting. The first
> statement should be a create view. The view is dropped and created
> "on-the-fly" with different where-clauses every time, depending on the
> user's search arguments. As I might
Tom Lane <[EMAIL PROTECTED]> writes:
> Palle Girgensohn <[EMAIL PROTECTED]> writes:
> > New facts: The problem "moved" when raising the -B from default (64)
> > to 1000 (-N 100 now). Now, here's what happens:
>
> Interesting.
I am also using -o -S 2048 now, but I doubt it helps...
> > query: C
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> New facts: The problem "moved" when raising the -B from default (64)
> to 1000 (-N 100 now). Now, here's what happens:
Interesting.
> query: CREATE VIEW wtabmaria AS SELECT
>p.personid,p.foretag,p.fnamn,p.enamn,p.titel,p.telefon,p.mobil,p.email,p.
Hi!
If needed, I'll try to provoke the error again, first recompiling with
-g. I will probably not find time for it before the week-end, though.
New facts: The problem "moved" when raising the -B from default (64)
to 1000 (-N 100 now). Now, here's what happens:
query: CREATE VIEW wtabmaria AS S
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> I have a problem with postgresl-7.0.2 on Freebsd 4-stable.
> query: declare curse cursor for select
>personid,foretag,fnamn,enamn,titel,telefon,mobil,email,tidpunkt, lower(foretag) from
>wtabmaria order by lower(foretag)
> query: fetch forward 20 f
15 matches
Mail list logo