From pgsql-general-owner+M19848=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 10:36:36 2002 Return-path: Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PFaZe16098 for ; Fri, 25 Jan 2002 10:36:36 -0500 (EST) Received: (qmail 35750 invoked by alias); 25 Jan 2002 15:34:38 -0000 Received: from unknown (HELO postgresql.org) (64.49.215.8) by www.postgresql.org with SMTP; 25 Jan 2002 15:34:38 -0000 Received: from sss.pgh.pa.us ([192.204.191.242]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PFDAl28120 for ; Fri, 25 Jan 2002 10:13:10 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PFCqf25364; Fri, 25 Jan 2002 10:12:52 -0500 (EST) To: Hiroshi Inoue cc: Bruce Momjian , Florian Wunderlich , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) In-Reply-To: <3C510D24.8E1FDF7F@tpf.co.jp> References: <200201250319.g0P3Jq022575@candle.pha.pa.us> <23244.1011932544@sss.pgh.pa.us> <3C510D24.8E1FDF7F@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue message dated "Fri, 25 Jan 2002 16:45:40 +0900" Date: Fri, 25 Jan 2002 10:12:51 -0500 Message-ID: <25361.1011971571@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-general-owner@postgresql.org Status: OR Hiroshi Inoue writes: > Tom Lane wrote: >> If it's not holding any locks, I can guarantee you it's not insensitive. >> Consider VACUUM, or even DROP TABLE. > It's already possible to keep a lock accross transactions. > So it would keep an AccessShareLock across transactions. AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore. We'd need to invent Yet Another lock type that would prevent VACUUM. Clearly that's perfectly doable. But: having just finished a lot of work to ensure that VACUUM could run in parallel with all "normal" database operations, I'm not that thrilled at the prospect of introducing a new mechanism that will block VACUUM. Especially not one that's *designed* to hold its lock for a long period of time. This will just get us right back into all the operational problems that lazy VACUUM was intended to get around. For example, this one: if transaction A has an insensitive-cursor lock on table T, and a VACUUM comes along to vacuum T and blocks waiting for the lock, then when subsequent transaction B wants to create an insensitive cursor on T it's going to be forced to queue up behind the VACUUM. While temp tables may seem like an ugly, low-tech way to support insensitive cursors, I think they may have more merit than you realize. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster From pgsql-general-owner+M19849=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 11:21:44 2002 Return-path: Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PGLhe19804 for ; Fri, 25 Jan 2002 11:21:44 -0500 (EST) Received: (qmail 65425 invoked by alias); 25 Jan 2002 16:15:14 -0000 Received: from unknown (HELO postgresql.org) (64.49.215.8) by www.postgresql.org with SMTP; 25 Jan 2002 16:15:14 -0000 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PG5il56844 for ; Fri, 25 Jan 2002 11:05:44 -0500 (EST) (envelope-from fwunderlich@devbrain.de) Received: from faxdial.hq.factor3.com (p3E9ED0CC.dip.t-dialin.net [62.158.208.204]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA07886; Fri, 25 Jan 2002 17:05:46 +0100 (MET) Received: from hq.factor3.com (florian@main.hq.factor3.com [192.168.1.2]) by faxdial.hq.factor3.com (8.11.1/8.11.0) with ESMTP id g0PG4P210606; Fri, 25 Jan 2002 17:04:25 +0100 Message-ID: <3C518231.F65DC636@hq.factor3.com> Date: Fri, 25 Jan 2002 17:05:05 +0100 From: Florian Wunderlich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane cc: Hiroshi Inoue , Bruce Momjian , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) References: <200201250319.g0P3Jq022575@candle.pha.pa.us> <23244.1011932544@sss.pgh.pa.us> <3C510D24.8E1FDF7F@tpf.co.jp> <25361.1011971571@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-general-owner@postgresql.org Status: OR Tom Lane wrote: > > Hiroshi Inoue writes: > > Tom Lane wrote: > >> If it's not holding any locks, I can guarantee you it's not insensitive. > >> Consider VACUUM, or even DROP TABLE. > > > It's already possible to keep a lock accross transactions. > > So it would keep an AccessShareLock across transactions. > > AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore. > We'd need to invent Yet Another lock type that would prevent VACUUM. > Clearly that's perfectly doable. > > But: having just finished a lot of work to ensure that VACUUM could run > in parallel with all "normal" database operations, I'm not that thrilled > at the prospect of introducing a new mechanism that will block VACUUM. > Especially not one that's *designed* to hold its lock for a long period > of time. This will just get us right back into all the operational > problems that lazy VACUUM was intended to get around. For example, this > one: if transaction A has an insensitive-cursor lock on table T, and a > VACUUM comes along to vacuum T and blocks waiting for the lock, then > when subsequent transaction B wants to create an insensitive cursor on T > it's going to be forced to queue up behind the VACUUM. Why do you have to lock the whole table when all you want is just one set of rows from a set of versions? Am I missing something here? When you're talking about in-transaction cursors for the above example, why would the cursor need anything more than the transaction A needs anyway? And for cross-transaction cursors, why lock the whole table when you could use the transaction information from the transaction in which the cursor was declared? Generally spoken, where's the difference between an insensitive persistent cursor and a still running transaction? > While temp tables may seem like an ugly, low-tech way to support > insensitive cursors, I think they may have more merit than you realize. Obviously, that's the easy way to do it, and lots of other databases make use of that already to implement insensitive cursors (see my other post). But as the long-term goal should be updateable insensitive persistent cursors, I think the temp table solution will get really messy. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html From pgsql-general-owner+M19851=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 11:50:42 2002 Return-path: Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PGoge22600 for ; Fri, 25 Jan 2002 11:50:42 -0500 (EST) Received: (qmail 80652 invoked by alias); 25 Jan 2002 16:45:09 -0000 Received: from unknown (HELO postgresql.org) (64.49.215.8) by www.postgresql.org with SMTP; 25 Jan 2002 16:45:09 -0000 Received: from sss.pgh.pa.us ([192.204.191.242]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PGOUl75295 for ; Fri, 25 Jan 2002 11:24:30 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PGOFf25891; Fri, 25 Jan 2002 11:24:15 -0500 (EST) To: Florian Wunderlich cc: Hiroshi Inoue , Bruce Momjian , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) In-Reply-To: <3C518231.F65DC636@hq.factor3.com> References: <200201250319.g0P3Jq022575@candle.pha.pa.us> <23244.1011932544@sss.pgh.pa.us> <3C510D24.8E1FDF7F@tpf.co.jp> <25361.1011971571@sss.pgh.pa.us> <3C518231.F65DC636@hq.factor3.com> Comments: In-reply-to Florian Wunderlich message dated "Fri, 25 Jan 2002 17:05:05 +0100" Date: Fri, 25 Jan 2002 11:24:15 -0500 Message-ID: <25888.1011975855@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-general-owner@postgresql.org Status: OR Florian Wunderlich writes: > When you're talking about in-transaction cursors for the above example, > why would the cursor need anything more than the transaction A needs > anyway? It wouldn't. > And for cross-transaction cursors, why lock the whole table when > you could use the transaction information from the transaction in which > the cursor was declared? The problem is to keep the rows that are supposed to be still visible to you from disappearing. If other backends think that transaction A is history, they will not think that they need to preserve rows that would have been visible to A, but are not visible to any still-running transaction. [ ... thinks for awhile ... ] Maybe we could extend the notion of "oldest XMIN" a little. Perhaps what each backend should record in the PROC array is not just the oldest XMIN visible to its current transaction, but the oldest XMIN visible to either its current xact or any of its open cross-transaction cursors. That together with an AccessShareLock on tables referenced by the cursors might work. A drawback of this approach is that opening a cursor and sitting on it for a long time would effectively defeat VACUUM activity --- it wouldn't be blocked, but it wouldn't be able to reclaim rows either. Anywhere, not only in the tables actually used by the cursor. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster From Inoue@tpf.co.jp Fri Jan 25 11:58:04 2002 Return-path: Received: from p2272.nsk.ne.jp ([210.145.18.145]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PGw3e24273 for ; Fri, 25 Jan 2002 11:58:03 -0500 (EST) Received: from mcadnote1 (ppm139.noc.fukui.nsk.ne.jp [61.198.95.39]) by p2272.nsk.ne.jp (8.9.3/3.7W-20000722) with SMTP id BAA07477; Sat, 26 Jan 2002 01:57:47 +0900 (JST) From: "Hiroshi Inoue" To: "Tom Lane" cc: "Bruce Momjian" , "Florian Wunderlich" , Subject: RE: [GENERAL] persistent portals/cursors (between transactions) Date: Sat, 26 Jan 2002 01:57:54 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <25361.1011971571@sss.pgh.pa.us> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Status: OR > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Hiroshi Inoue writes: > > Tom Lane wrote: > >> If it's not holding any locks, I can guarantee you it's not > insensitive. > >> Consider VACUUM, or even DROP TABLE. > > > It's already possible to keep a lock accross transactions. > > So it would keep an AccessShareLock across transactions. > > AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore. Really ? VACUUM FULL conflicts with AccessShareLock from the first. If new vacuum does wrong thing with persistent read-only cursors it would do the wrong thing with the current cursors as well. Of cource as Vadim mentioned before, HeapTupleSatisfiesVacuum() should take the transaction id in which the cursor was opened into account. regards, Hiroshi Inoue From pgsql-general-owner+M19852=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 12:04:58 2002 Return-path: Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PH4ve25258 for ; Fri, 25 Jan 2002 12:04:57 -0500 (EST) Received: (qmail 91567 invoked by alias); 25 Jan 2002 17:04:25 -0000 Received: from unknown (HELO postgresql.org) (64.49.215.8) by www.postgresql.org with SMTP; 25 Jan 2002 17:04:25 -0000 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PGxNl89850 for ; Fri, 25 Jan 2002 11:59:23 -0500 (EST) (envelope-from fwunderlich@devbrain.de) Received: from faxdial.hq.factor3.com (p3E9ED0CC.dip.t-dialin.net [62.158.208.204]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA15976; Fri, 25 Jan 2002 17:59:27 +0100 (MET) Received: from hq.factor3.com (florian@main.hq.factor3.com [192.168.1.2]) by faxdial.hq.factor3.com (8.11.1/8.11.0) with ESMTP id g0PGwC210992; Fri, 25 Jan 2002 17:58:12 +0100 Message-ID: <3C518EC9.FDE6DDC3@hq.factor3.com> Date: Fri, 25 Jan 2002 17:58:49 +0100 From: Florian Wunderlich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane cc: Hiroshi Inoue , Bruce Momjian , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) References: <200201250319.g0P3Jq022575@candle.pha.pa.us> <23244.1011932544@sss.pgh.pa.us> <3C510D24.8E1FDF7F@tpf.co.jp> <25361.1011971571@sss.pgh.pa.us> <3C518231.F65DC636@hq.factor3.com> <25888.1011975855@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-general-owner@postgresql.org Status: OR > > And for cross-transaction cursors, why lock the whole table when > > you could use the transaction information from the transaction in which > > the cursor was declared? > > The problem is to keep the rows that are supposed to be still visible to > you from disappearing. If other backends think that transaction A is > history, they will not think that they need to preserve rows that would > have been visible to A, but are not visible to any still-running > transaction. > > [ ... thinks for awhile ... ] Maybe we could extend the notion of > "oldest XMIN" a little. Perhaps what each backend should record in the > PROC array is not just the oldest XMIN visible to its current > transaction, but the oldest XMIN visible to either its current xact or > any of its open cross-transaction cursors. That together with an > AccessShareLock on tables referenced by the cursors might work. > > A drawback of this approach is that opening a cursor and sitting on it > for a long time would effectively defeat VACUUM activity --- it wouldn't > be blocked, but it wouldn't be able to reclaim rows either. Anywhere, > not only in the tables actually used by the cursor. Isn't that exactly what beginning a transaction and keeping it uncommitted for a long time would do too? I see the problem - your last sentence - but getting rid of that would mean to not only save an oldest XMIN, but also a reference to all tables that this not-quite-a-xact uses, kind of like a "selective transaction". I doubt that there really are any problems in the real world though, so having a naive implementation first would be fine too. So from the vacuum perspective, it looks like more than just one transaction is running per backend, right? Probably I don't understand anything at all, or that's what I suggested way back in my second or third mail. Whatever. Assuming I understood a bit here, a read-write cross-transaction cursor shouldn't be too hard to implement then either. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-general-owner+M19855=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 12:21:10 2002 Return-path: Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PHLAe26624 for ; Fri, 25 Jan 2002 12:21:10 -0500 (EST) Received: (qmail 97865 invoked by alias); 25 Jan 2002 17:15:35 -0000 Received: from unknown (HELO postgresql.org) (64.49.215.8) by www.postgresql.org with SMTP; 25 Jan 2002 17:15:35 -0000 Received: from sss.pgh.pa.us ([192.204.191.242]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PH6Nl94616 for ; Fri, 25 Jan 2002 12:06:23 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PH69f26446; Fri, 25 Jan 2002 12:06:09 -0500 (EST) To: "Hiroshi Inoue" cc: "Bruce Momjian" , "Florian Wunderlich" , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) In-Reply-To: References: Comments: In-reply-to "Hiroshi Inoue" message dated "Sat, 26 Jan 2002 01:57:54 +0900" Date: Fri, 25 Jan 2002 12:06:08 -0500 Message-ID: <26443.1011978368@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-general-owner@postgresql.org Status: OR "Hiroshi Inoue" writes: >> AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore. > Really ? VACUUM FULL conflicts with AccessShareLock from the > first. I was speaking of lazy VACUUM, of course. > If new vacuum does wrong thing with persistent read-only cursors > it would do the wrong thing with the current cursors as well. No, because current cursors don't span transactions. > Of cource as Vadim mentioned before, HeapTupleSatisfiesVacuum() > should take the transaction id in which the cursor was opened into > account. I haven't read all of that thread yet; maybe Vadim already had the idea I just had of playing games with oldest-XMIN. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly From tgl@sss.pgh.pa.us Fri Jan 25 12:07:42 2002 Return-path: Received: from sss.pgh.pa.us (root@[192.204.191.242]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PH7fe25517 for ; Fri, 25 Jan 2002 12:07:41 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PH7Pf26466; Fri, 25 Jan 2002 12:07:25 -0500 (EST) To: Florian Wunderlich cc: Hiroshi Inoue , Bruce Momjian , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) In-Reply-To: <3C518EC9.FDE6DDC3@hq.factor3.com> References: <200201250319.g0P3Jq022575@candle.pha.pa.us> <23244.1011932544@sss.pgh.pa.us> <3C510D24.8E1FDF7F@tpf.co.jp> <25361.1011971571@sss.pgh.pa.us> <3C518231.F65DC636@hq.factor3.com> <25888.1011975855@sss.pgh.pa.us> <3C518EC9.FDE6DDC3@hq.factor3.com> Comments: In-reply-to Florian Wunderlich message dated "Fri, 25 Jan 2002 17:58:49 +0100" Date: Fri, 25 Jan 2002 12:07:24 -0500 Message-ID: <26463.1011978444@sss.pgh.pa.us> From: Tom Lane Status: OR Florian Wunderlich writes: > Isn't that exactly what beginning a transaction and keeping it > uncommitted for a long time would do too? Sure, but then you haven't got a cross-transaction cursor, only a plain cursor. regards, tom lane From Inoue@tpf.co.jp Fri Jan 25 12:23:39 2002 Return-path: Received: from p2272.nsk.ne.jp (p2272.nsk.ne.jp [210.145.18.145]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PHNce26772 for ; Fri, 25 Jan 2002 12:23:38 -0500 (EST) Received: from mcadnote1 (ppm103.noc.fukui.nsk.ne.jp [61.198.95.3]) by p2272.nsk.ne.jp (8.9.3/3.7W-20000722) with SMTP id CAA08121; Sat, 26 Jan 2002 02:23:18 +0900 (JST) From: "Hiroshi Inoue" To: "Florian Wunderlich" cc: "Bruce Momjian" , "Tom Lane" , , "Jan Wieck" Subject: RE: [GENERAL] persistent portals/cursors (between transactions) Date: Sat, 26 Jan 2002 02:23:26 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C515739.74CCA819@hq.factor3.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Status: OR > -----Original Message----- > From: florian@hq.factor3.com [mailto:florian@hq.factor3.com]On > > > Hiroshi, that's exactly what I need, though I am not sure if we are all > really talking about the same thing. > > In case I misunderstood something: as far as I know, SQL92 defines that > a cursor is by default sensitive, which means that it displays the data > from all comitted transactions at any time. If the data changes, so does > what the cursor returns. AFAIK SQL92's default is indeterminate which guarantees nothing about sensitivity. Though we don't have insensitive cursors yet INSENSITIVE cursors are very natural for MVCC and it's not hard to implement. In reality the current cursors see no changes after the cursor was opened other than the ones made by the bakend itself. regards, Hiroshi Inoue From pgsql-general-owner+M19860=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 13:16:18 2002 Return-path: Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9]) by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PIGHe03507 for ; Fri, 25 Jan 2002 13:16:17 -0500 (EST) Received: (qmail 25543 invoked by alias); 25 Jan 2002 18:14:36 -0000 Received: from unknown (HELO postgresql.org) (64.49.215.8) by www.postgresql.org with SMTP; 25 Jan 2002 18:14:36 -0000 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PHjpl13108 for ; Fri, 25 Jan 2002 12:45:51 -0500 (EST) (envelope-from fwunderlich@devbrain.de) Received: from faxdial.hq.factor3.com (p3E9ED0CC.dip.t-dialin.net [62.158.208.204]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id SAA01771; Fri, 25 Jan 2002 18:45:55 +0100 (MET) Received: from hq.factor3.com (florian@main.hq.factor3.com [192.168.1.2]) by faxdial.hq.factor3.com (8.11.1/8.11.0) with ESMTP id g0PHiO211360; Fri, 25 Jan 2002 18:44:24 +0100 Message-ID: <3C51999B.260171D6@hq.factor3.com> Date: Fri, 25 Jan 2002 18:44:59 +0100 From: Florian Wunderlich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane cc: Hiroshi Inoue , Bruce Momjian , pgsql-general@postgresql.org Subject: Re: [GENERAL] persistent portals/cursors (between transactions) References: <200201250319.g0P3Jq022575@candle.pha.pa.us> <23244.1011932544@sss.pgh.pa.us> <3C510D24.8E1FDF7F@tpf.co.jp> <25361.1011971571@sss.pgh.pa.us> <3C518231.F65DC636@hq.factor3.com> <25888.1011975855@sss.pgh.pa.us> <3C518EC9.FDE6DDC3@hq.factor3.com> <26463.1011978444@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-general-owner@postgresql.org Status: OR Tom Lane wrote: > > Isn't that exactly what beginning a transaction and keeping it > > uncommitted for a long time would do too? > > Sure, but then you haven't got a cross-transaction cursor, only a plain > cursor. Sorry for being unclear - I wanted to say that this problem obviously already exists, so there's not a new (conceptual) problem here. I'm sure you read the second part of my post where I suggested what a possible solution could look like. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html