Re: Beating Oracle

From: <jtv(at)xs4all(dot)nl>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <bbadger(at)BadgerSE(dot)com>, <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: Beating Oracle
Date: 2002-03-01 13:08:23
Message-ID: 6429.195.212.29.105.1014988103.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

> The reason I'm so unenthused about this is that I think it'd be quite
> difficult to do transparently at the database level. (1) How can you
> know where communication was lost, from the other end's point of view?

Actually, if we're talking about transient TCP failures here (ie. one in X
connections dies halfway through a transaction), then [1]libpqxx does have
the logic built-in for semi-transparent connection recovery.

I'm not sure this is quite what is needed here, but what it does right now
is reset the backend connection (PQreset() I think the function was),
forget about the current attempt at performing the transaction, and re-
running the client code that makes up the transaction. So we're not
talking about a simple replay of old SQL, but a simple framework for
writing restartable code that "plugs into" a connection. Look for the
Transactor base class.

If PQreset() is not sufficient, I see no fundamental problem in doing an
entire new connect instead.

The one underlying assumption of course is that the client side will know
if the connection was lost. If TCP and libpq guarantee that much, then the
libpqxx mechanism should solve the problem perfectly. All we need now is
two-phase commit. :-)

> (eg, client has no idea whether database completed the last request
> sent.) I think you'd wind up reimplementing TCP, or something much
> like it, just to deal with that aspect of the problem. (2) How can you
> even be sure that you're reconnecting to the same other-end session?
> Opportunities for security holes seem rampant. (3) Should the database
> hold sessions open indefinitely, waiting to see if the client can be
> recontacted? Won't take too long until your session limit is entirely
> filled by dead connections.

Basically, libpqxx solves these problems at the client side--it doesn't try
to reconnect to an older session, but simply leaves the old session to
wither and die while it starts up a new one to perform the same task. This
takes very little in the way of state-keeping on either side.

Jeroen

[1] http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Ted Petrosky 2002-03-01 13:28:37 help understanding libpq++
Previous Message Bruce Badger 2002-03-01 04:47:29 Re: Beating Oracle