Skip to content

unnamed prepared statement does not exist #19

Closed
datacompboy opened this Issue Jun 18, 2012 · 18 comments

3 participants

@datacompboy

I'm sometimes get the
{error,error,<<"26000">>, <<"unnamed prepared statement does not exist">>, []}
error -- why it can be ?!
just re-send that query again fixes it

@wg
Owner
wg commented Jun 18, 2012

Hello, can you share either a reproducible test case or the sequence of epgsql calls you're making when this happens?

@datacompboy

nothing intresting -- just sequence of insert / update / selects; no any visible errors/delays noticed, and just query retry enough to get it processed correctly.
postgresql 9.0 and 8.3, same app.
thru psql driver (used before epgsql driver) -- never seen that problem (but psql have his own troubles)

@datacompboy

All queries without arguments (esql used to convert tuple to query)

@wg
Owner
wg commented Jun 18, 2012

Thank you for the details! You said you aren't passing any parameters to the query? Are you building SQL strings on the fly instead?

@datacompboy
q(Esql) ->
    case catch erlsql:sql(Esql) of
        {error, _} = Err ->
            throw(Err);
        Sql ->
            q2(Sql)
    end.

q2(Statement) ->
    q2(Statement, 2).

q2(_Statement, 0) ->
    {error, {error,error,<<"26000">>, <<"unnamed prepared statement does not exist">>, []}};

q2(Statement, N) ->
    case pgsql:equery(?MODULE, Statement) of
    {error, {error,error,<<"26000">>, _, _}} -> q2(Statement, N-1);
        {ok, _Cols, Rows} -> {ok, Rows};
        {ok, Count} -> {ok, Count};
        {ok, _Count, _Cols, Rows} -> {ok, Rows};
        {error, Error} -> {error, Error}
    end.
@datacompboy

Also, in production pgsql:equery called from several processes in parallel;
i have unable to reproduce bug in any simple tests, but in production (under high volume of queries) i see that problem quite often -- around 1-2-3 messages in sequence around every 10-15 minutes.

@wg
Owner
wg commented Jun 18, 2012

Ahh, are you sharing one connection between multiple processes? That won't work, epgsql is designed for only one process to own a single connection, else you must use some form of pooling.

@datacompboy

Hmm... But what async branch for?

@wg
Owner
wg commented Jun 18, 2012

I've seen the async fork but I'm not sure what it does exactly. Would suspect it's more so a process can get async messages with query results. PostgreSQL connections are stateful, so things could get really messed up if two processes attempted to use one simultaneously.

@datacompboy

Thanks, sorry for bother you. Will try to reproduce locally, and rewrite to single process if that only solution.

@wg
Owner
wg commented Jun 18, 2012

No bother at all! There are a few forks of epgsql_pool on github you might want to try, although I prefer a design that pools db accessor processes, each one owning its own connection. That way a supervisor can restart the accessor processes on any db restarts or failures.

Best of luck getting your app up and running =)

@wg wg closed this Jun 18, 2012
@mabrek
mabrek commented Jun 19, 2012

Were you talking about my async fork? It allows to use single connection from several processes in auto commit mode.

@datacompboy

Agh, yes. It's your fork used, so that issue for you, not for wg :)

@mabrek
mabrek commented Jun 19, 2012

Could you raise an issue in my repository?

@mabrek
mabrek commented Jun 19, 2012

It's a bug in the compatibility layer, equery was implemented not in atomic way. It can be workarounded by using squery in your case since you don't have query parameters.
Or you can use parse/bind/execute with unique names for statements and portals.

@mabrek
mabrek commented Jun 19, 2012

oops, enabled issues on my repository

@mabrek
mabrek commented Jun 19, 2012

further discussion moved to mabrek#1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.