- Original Message -
From: Jeroen T. Vermeulen [EMAIL PROTECTED]
I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels
this February) for libpqxx. My code tries to compensate for the
possibility that the backend connection is lost while waiting for a reply
to a
- Original Message -
From: Jeroen T. Vermeulen [EMAIL PROTECTED]
I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels
this February) for libpqxx. My code tries to compensate for the
possibility that the backend connection is lost while waiting for a reply
to a
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
How much later? clog is not kept forever.
Due to my setup, I could assure, that for the XID I ask for always
(ShmemVariableCache-nextXid - XID) C (and C is in my case something
around 150).
holds. A possible solution could be
On Fri, Jun 20, 2003 at 09:35:08AM +0200, Christian Plattner wrote:
I see a race condition in this approach: if you reconnect too fast, and the
backend which actually should commit is still in progress (assume it takes a
while to commit for whatever reasons) you get the impression that it did
- Original Message -
From: Jeroen T. Vermeulen [EMAIL PROTECTED]
I see a race condition in this approach: if you reconnect too fast, and
the
backend which actually should commit is still in progress (assume it
takes a
while to commit for whatever reasons) you get the impression
On Fri, Jun 20, 2003 at 10:20:14AM +0200, Christian Plattner wrote:
Well, I wouldn't rely solely on TCP when assuring consistency. Also, I don't
think that the backend will ever inspect its TCP socket while committing.
No, but its underlying IP stack would.
btw: There could be also other
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
How much later? clog is not kept forever.
I took a deeper look into the source. Forget my last posting.
As far as I understand your code there is only one chance that information
in clog gets lost:
If XIDs are reused then
- Original Message -
From: Jeroen T. Vermeulen [EMAIL PROTECTED]
btw: There could be also other reasons for the client to loose the
connection (i.e. client process crashes).
In that case the client would lose all its state as well, so not really
a problem that can be handled
On Fri, Jun 20, 2003 at 02:41:29PM +0200, Christian Plattner wrote:
Well, my client (actually it is a middleware layer which routes transactions
to a set of replicas) keeps its own log, because it must be able to handle
arbitary failures. So it never looses its state.
In that case perhaps we
Christian Plattner [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
How much later? clog is not kept forever.
... Ofcourse one should not do a
VACUUM FULL while not being sure about the status of a transaction in the
past :)
As long as you haven't done a cluster-wide VACUUM, clog
Christian Plattner [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
How much later? clog is not kept forever.
As far as I understand your code there is only one chance that information
in clog gets lost:
If XIDs are reused then ExtendCLOG will overwrite existing entries.
Also, it
Christian Plattner [EMAIL PROTECTED] writes:
Do be able to handle all sorts of failures I needed two functions:
- A function to get the current XID
- A function which I can use later to tell if a given XID
commited/aborted/whatever
How much later? clog is not kept forever.
On Thu, Jun 19, 2003 at 05:16:10PM +0200, Christian Plattner wrote:
Do be able to handle all sorts of failures I needed two functions:
- A function to get the current XID
- A function which I can use later to tell if a given XID
commited/aborted/whatever
I ran into the same need (Bruce,
13 matches
Mail list logo
