X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id E38CA3B728C for ; Thu, 16 Dec 2004 18:05:38 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 85044-05 for ; Thu, 16 Dec 2004 18:05:31 +0000 (GMT) Received: from stark.xeocode.com (gsstark.mtl.istop.com [66.11.160.162]) by svr1.postgresql.org (Postfix) with ESMTP id 7D01F3B7240 for ; Thu, 16 Dec 2004 18:05:29 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1Cf00B-0001jp-00; Thu, 16 Dec 2004 13:05:23 -0500 To: Jens Lechtenboerger Cc: Greg Stark , Jan Wieck , pgsql-interfaces@postgresql.org Subject: Re: Lost updates vs resumable connections/transactions References: <41C06961.8020406@Yahoo.com> <87is73qrde.fsf@stark.xeocode.com> In-Reply-To: From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 16 Dec 2004 13:05:22 -0500 Message-ID: <876532p199.fsf@stark.xeocode.com> Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.049 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200412/26 X-Sequence-Number: 5196 Jens Lechtenboerger 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