Tom Lane wrote:
Geoffrey <[EMAIL PROTECTED]> writes:
I've done some further research on this problem. I'm not a big user of
strace, so I'm looking at getting some insight here. Basically, there
are two different versions of the pcmiler libraries. One set works, the
other does not. The foll
Tom Lane wrote:
Geoffrey <[EMAIL PROTECTED]> writes:
I've done some further research on this problem. I'm not a big user of
strace, so I'm looking at getting some insight here. Basically, there
are two different versions of the pcmiler libraries. One set works, the
other does not. The foll
Geoffrey <[EMAIL PROTECTED]> writes:
> I've done some further research on this problem. I'm not a big user of
> strace, so I'm looking at getting some insight here. Basically, there
> are two different versions of the pcmiler libraries. One set works, the
> other does not. The following is t
Geoffrey wrote:
I forgot to mention the one difference I did see in the strace output.
I don't understand why there would be difference in the call parms to
poll(). Then again, I'm not altogether sure what code is calling poll
at this point. I'm assuming it's from the database engine. I've n
I've done some further research on this problem. I'm not a big user of
strace, so I'm looking at getting some insight here. Basically, there
are two different versions of the pcmiler libraries. One set works, the
other does not. The following is the strace output from both processes.
The f
Geoffrey <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, this trace doesn't prove any such thing. If it was a wild jump,
>> we can surmise that it landed someplace in the first few instructions of
>> FileRead (before the call to FileAccess), but there's no proof here that
>> it landed on-th
Tom Lane wrote:
Geoffrey <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The trace is *really* suspicious given what you say here. I'm inclined
to think that what is really happening is that something is jumping to
never-never land (via a clobbered function pointer or overwriting a
return address
Geoffrey <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The trace is *really* suspicious given what you say here. I'm inclined
>> to think that what is really happening is that something is jumping to
>> never-never land (via a clobbered function pointer or overwriting a
>> return address on the
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Geoffrey wrote:
CREATE OR REPLACE FUNCTION pcm_getmiles_s(text,text,integer)
RETURNS float8 AS '/esc/pgrnd/prog/libpcmiler'
LANGUAGE 'c' WITH (isStrict);
Is this function actually a PostgreSQL callable function? Or is it just
a gene
Tom Lane wrote:
Geoffrey <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Is pcmiler a Postgres-specific backend extension?
No. It's a standalone application that provides an api to build calls
into there product from other applications. What we've done is created
functions that are called fro
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Geoffrey wrote:
>>> CREATE OR REPLACE FUNCTION pcm_getmiles_s(text,text,integer)
>>> RETURNS float8 AS '/esc/pgrnd/prog/libpcmiler'
>>> LANGUAGE 'c' WITH (isStrict);
>
>> Is this function actually a PostgreSQL callable function? Or i
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Geoffrey wrote:
>> CREATE OR REPLACE FUNCTION pcm_getmiles_s(text,text,integer)
>> RETURNS float8 AS '/esc/pgrnd/prog/libpcmiler'
>> LANGUAGE 'c' WITH (isStrict);
> Is this function actually a PostgreSQL callable function? Or is it just
> a general C f
Geoffrey wrote:
> Tom Lane wrote:
>> Geoffrey <[EMAIL PROTECTED]> writes:
>>> A backtrace against this process produces:
>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0814acc9 in FileAccess (file=168481968) at fd.c:717
>>> 717 if (FileIsNotOpen(file))
>>> (gdb) bt
>>
Geoffrey <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 0x0814acc9 in FileAccess (file=168481968) at fd.c:717
> #1 0x0814b2e7 in FileRead (file=168481968, buffer=0xbff816ce "", amount=2)
> at fd.c:972
> #2 0x00203ecc in ?? ()
> #3 0x0a0ad4b0 in ?? ()
> #4 0xbff816ce in ?? ()
> #5 0x0002
Geoffrey <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Is pcmiler a Postgres-specific backend extension?
> No. It's a standalone application that provides an api to build calls
> into there product from other applications. What we've done is created
> functions that are called from the data
Tom Lane wrote:
Geoffrey <[EMAIL PROTECTED]> writes:
A backtrace against this process produces:
Program received signal SIGSEGV, Segmentation fault.
0x0814acc9 in FileAccess (file=168481968) at fd.c:717
717 if (FileIsNotOpen(file))
(gdb) bt
#0 0x0814acc9 in FileAccess (file=16848
Geoffrey <[EMAIL PROTECTED]> writes:
> A backtrace against this process produces:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0814acc9 in FileAccess (file=168481968) at fd.c:717
> 717 if (FileIsNotOpen(file))
> (gdb) bt
> #0 0x0814acc9 in FileAccess (file=168481968) at
We have built into the backend of the database a third party application
called pcmiler that produces mileage between two locations. This has
been working in the past, but after upgrading to RHEL 4, Postgresql
7.4.16 and pcmiler 20 (from pcmiler 17), the server process is
terminated with a sig
18 matches
Mail list logo
