From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
---|---|
To: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | libpqxx & lost connections |
Date: | 2002-03-03 15:35:40 |
Message-ID: | 20020303153540.GA653@bulletproof |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
I've just added some plumbing to libpqxx that checks for lost
connections while a transaction is being committed. As discussed here
last week, in that situation there is no way to tell whether the
transaction really succeeded or not and the only things a front-end
library can do are to (i) warn the user, and (ii) not retry the
transaction.
At some piont I would like to go to the next stage and try to deal with
these situations as soon as the connection is re-established. I could
do this by setting up a "user-level transaction log" table, but I do
expect that to be a significant performance drain and source of
complexity.
Alternatively, perhaps it would be possible to expose a minimal query
interface to the transaction log, so the front-end would have a fighting
chance of reconnecting and figuring out what happened to its last
transaction (committed / aborted / don't remember). I don't know
enough about the back-end to see if this would be feasible, and I do
realize it would probably require a change to the frontend-backend
interface (like maybe sending a transaction ID back as a result for a
BEGIN WORK statement, and adding a "check transaction" internal query).
But a useful thing to keep in mind for the future perhaps?
Find the new code at
http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-03 20:12:04 | Re: May we use libpgtcl pg_execute? / Was: pg_select... |
Previous Message | ljb | 2002-03-03 02:13:52 | May we use libpgtcl pg_execute? / Was: pg_select... |