Thread: FastPath blocked when ERROR is thrown
HI
I used java API FastPath.fastpath(fid, ...) to call a C function
PGfn(conn, fid,...) in the kernal. But if there is an exception (i.e.,
ERROR messages is thrown in the backend due to elog(ERROR, ...)), the
FastPath.fastpath(fid, ..) is blocked and never returns. The DB backend is
also dead. I have to "pkill -9 post" in order to restore everything. Can
anyone give a clue of what the problems should be? Where should are the
bugs possibly located?
The java codes is attached:
public boolean putWriteSet(java.sql.Connection conn, byte[] writeSet)
throws SQLException
{
Fastpath fp = ((org.postgresql.Connection)conn).getFastpathAPI();
FastpathArg[] args = new FastpathArg[1];
args[0] = new FastpathArg(writeSet);
fp.fastpath(2075, false, args); //to apply writeset, indirectly call
PQfn(conn, 2075, ...) implemented in the kernal in C.
return true;
}
I am not the original author of C version PQfn(.,2075,..) so I have no
idea where and how to debug it. I doubt that the blocking is due to
implementation of C part instead of Java part. But I don't know how to
start my debugging.
thanks in advance!
=======================================
Yi Lin
Ph.D. candidate
School of Computer Science
McGill University
Montreal, Quebec,Canada
URL: http://www.cs.mcgill.ca/~ylin30/
\\\ $ ///
@ @
======o0o==0==o0o======================
If you managed to kill the backend, then it's likely the C function
that did it. In order to debug it you can use gdb
Can you call the C function from psql without crashing ?
Dave
On 11-Apr-06, at 6:06 PM, Yi Lin wrote:
> HI
>
> I used java API FastPath.fastpath(fid, ...) to call a C function
> PGfn(conn, fid,...) in the kernal. But if there is an exception (i.e.,
> ERROR messages is thrown in the backend due to elog(ERROR, ...)), the
> FastPath.fastpath(fid, ..) is blocked and never returns. The DB
> backend is
> also dead. I have to "pkill -9 post" in order to restore
> everything. Can
> anyone give a clue of what the problems should be? Where should are
> the
> bugs possibly located?
>
> The java codes is attached:
>
> public boolean putWriteSet(java.sql.Connection conn, byte[] writeSet)
> throws SQLException
> {
> Fastpath fp = ((org.postgresql.Connection)conn).getFastpathAPI();
> FastpathArg[] args = new FastpathArg[1];
> args[0] = new FastpathArg(writeSet);
> fp.fastpath(2075, false, args); //to apply writeset,
> indirectly call
> PQfn(conn, 2075, ...) implemented in the kernal in C.
>
> return true;
> }
>
> I am not the original author of C version PQfn(.,2075,..) so I have no
> idea where and how to debug it. I doubt that the blocking is due to
> implementation of C part instead of Java part. But I don't know how to
> start my debugging.
>
> thanks in advance!
>
> =======================================
> Yi Lin
>
> Ph.D. candidate
> School of Computer Science
> McGill University
> Montreal, Quebec,Canada
> URL: http://www.cs.mcgill.ca/~ylin30/
>
> \\\ $ ///
> @ @
> ======o0o==0==o0o======================
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
On Tue, 11 Apr 2006, Yi Lin wrote: > I used java API FastPath.fastpath(fid, ...) to call a C function > PGfn(conn, fid,...) in the kernal. But if there is an exception (i.e., > ERROR messages is thrown in the backend due to elog(ERROR, ...)), the > FastPath.fastpath(fid, ..) is blocked and never returns. The attached code runs fine with the cvs jdbc driver and a 8.0.7 server. You haven't mentioned your versions, but this code hasn't changed recently so anything relatively new should be fine. How do you know the function is erroring out? What does the server log say? Kris Jurka
Attachment
HI Kris Jurka: >> I used java API FastPath.fastpath(fid, ...) to call a C function >> PGfn(conn, fid,...) in the kernal. But if there is an exception (i.e., >> ERROR messages is thrown in the backend due to elog(ERROR, ...)), the >> FastPath.fastpath(fid, ..) is blocked and never returns. >> > > The attached code runs fine with the cvs jdbc driver and a 8.0.7 server. > You haven't mentioned your versions, but this code hasn't changed recently > so anything relatively new should be fine. > I am using a modified version of Postgresql 7.2. It was modified by adding Writeset functionality needed by replication such as Postgres-R. The function Fastpath.fastpath(2075, ..) -> PQfn(conn, 2075, ..) in the attached codes will trigger a non-standard function putWriteset() implemented by one previous student in my lab. So I don't think you tested the attached codes against the PQfn(..) which I am worried about. It seems to me that the exception caused by elog(ERROR, ..) is not thrown upto Fastpath.fastpath(2075, ..). But I know so little about the kernal of postgresql that I can't trace the bug. Could u please give me some hints (e.g., the functions or files to examinate)? I am going to check if the C version PQfn(..) will be blocked by ERROR or not. > How do you know the function is erroring out? What does the server log > say? I intentionally inserted a tuple twice in two separated txns hence the second insertion txn would cause an ERROR message. And then the function fastpath(..) gets blocked forever. The error message is sth like: ERROR: can't insert the same key to index t_a_pk_index twice. Tuple exists already. To abort the transaction (No Error). Sorry I don't know how to read server logs at all. thanks a lot! Yi > > Kris Jurka ======================================= Yi Lin Ph.D. candidate School of Computer Science McGill University Montreal, Quebec,Canada URL: http://www.cs.mcgill.ca/~ylin30/ \\\ $ /// @ @ ======o0o==0==o0o======================
On Tue, 11 Apr 2006, Yi Lin wrote: > I am using a modified version of Postgresql 7.2. It was modified by adding > Writeset functionality needed by replication such as Postgres-R. The > function Fastpath.fastpath(2075, ..) -> PQfn(conn, 2075, ..) in the > attached codes will trigger a non-standard function putWriteset() I don't know how to help you. You've got a very non-standard postgresql version and are doing unusual things with it (fastpath calls). Unless you can demonstrate that the JDBC driver is doing something wrong you should ask on another list, perhaps a postgres-r specific one. Kris Jurka