Re: Lost updates vs resumable connections/transactions
От | Greg Stark |
---|---|
Тема | Re: Lost updates vs resumable connections/transactions |
Дата | |
Msg-id | 876532p199.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Lost updates vs resumable connections/transactions (Jens Lechtenbörger <lechtej@uni-muenster.de>) |
Список | 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 по дате отправления: