Re: Lost updates vs resumable connections/transactions - Mailing list pgsql-interfaces

From Greg Stark
Subject Re: Lost updates vs resumable connections/transactions
Date
Msg-id 876532p199.fsf@stark.xeocode.com
Whole thread Raw
In response to Lost updates vs resumable connections/transactions  (Jens Lechtenbörger <lechtej@uni-muenster.de>)
List pgsql-interfaces
Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:

> But why should I have SQLRelay between me and the database?
> I don't plan to use any of its "real" features.  It would just be a
> proxy with a known address that maintains a database connection.
> Obviously, the database server itself has a known address and
> maintains database connections...

The problem is that a database session keeps more state than just a
transaction id. It also keeps locks and other resources that would need to be
put aside in RAM. And for something like Apache where the new request could be
coming in to a different backend, these resources would have to be migrated to
the new backend when the session is resumed.

It could be done, but the most direct way to do it would be to keep around the
entire backend using something like SQLRelay. The resources used by SQLRelay
itself aren't really the concern here. They're dwarfed by the resources pinned
down by the database backends being kept around waiting in case the
application user comes back.

-- 
greg



pgsql-interfaces by date:

Previous
From: Greg Stark
Date:
Subject: Re: Lost updates vs resumable connections/transactions
Next
From: Jan Wieck
Date:
Subject: Re: Lost updates vs resumable connections/transactions