From: | "Christian Plattner" <postgresql(at)sioux(dot)ch> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Access to transaction status |
Date: | 2003-06-20 08:20:14 |
Message-ID: | 00e101c33704$c6811110$6e828481@ethz.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
----- Original Message -----
From: "Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl>
> > 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
not
> > commit - and a short time later the backend will commit... (before
noticing
> > that the client connection was lost).
>
> Good point. So far I assumed that a broken connection would take a while
> to repair. OTOH by the time TCP gives up due to a bad network connection,
> wouldn't the server reach the same conclusion?
>
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.
btw: There could be also other reasons for the client to loose the
connection (i.e. client process crashes).
- Christian
From | Date | Subject | |
---|---|---|---|
Next Message | Nigel J. Andrews | 2003-06-20 08:41:11 | Re: Two weeks to feature freeze |
Previous Message | Jeroen T. Vermeulen | 2003-06-20 08:04:18 | Re: Access to transaction status |