Philipp Reisner <[EMAIL PROTECTED]> writes:
> strncpy(fstr, (cp + 1), 7);
> + fstr[7]=0;
> strcpy((fstr + strlen(fstr)), "00");
After some looking around, it turns out there was another similar error,
plus several related pl
Philipp Reisner <[EMAIL PROTECTED]> writes:
> We (Clifford Wolf and me) have found the bug!
Good work! The INT64_TIMESTAMP code isn't very widely used, I think,
which probably explains why this wasn't noticed before. Will commit
the patch shortly.
regards, tom lane
---
Am Donnerstag, 31. Juli 2003 15:53 schrieb Tom Lane:
> Philipp Reisner <[EMAIL PROTECTED]> writes:
> > Program received signal SIGSEGV, Segmentation fault.
> > DecodeDateTime (field=Cannot access memory at address 0x303038
> > ) at datetime.c:1404
> > 1404datetime.c: No such file or directory.
Philipp Reisner <[EMAIL PROTECTED]> writes:
> Program received signal SIGSEGV, Segmentation fault.
> DecodeDateTime (field=Cannot access memory at address 0x303038
> ) at datetime.c:1404
> 1404datetime.c: No such file or directory.
> in datetime.c
> (gdb) where
> #0 DecodeDateTime (fie
Am Mittwoch, 30. Juli 2003 16:00 schrieb Tom Lane:
> Philipp Reisner <[EMAIL PROTECTED]> writes:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0812f9bc in DecodeDateTime ()
> > (gdb) where
> > #0 0x0812f9bc in DecodeDateTime ()
> > Cannot access memory at address 0xbf003030
>
> Th
Philipp Reisner <[EMAIL PROTECTED]> writes:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0812f9bc in DecodeDateTime ()
> (gdb) where
> #0 0x0812f9bc in DecodeDateTime ()
> Cannot access memory at address 0xbf003030
That's a fairly large routine :-(. Could I trouble you to rebuild w
Am Montag, 28. Juli 2003 15:53 schrieb Tom Lane:
> Philipp Reisner <[EMAIL PROTECTED]> writes:
> > If I execute this query several times (I receive the correct result set),
> > and then do an explain of the same query, the backend terminates with
> > sig 11 !!!
>
> Can you get us a debugger stack t
Philipp Reisner <[EMAIL PROTECTED]> writes:
> If I execute this query several times (I receive the correct result set),
> and then do an explain of the same query, the backend terminates with
> sig 11 !!!
Can you get us a debugger stack trace from the crash?
Also you should specify the platform y
