From: Bruce Momjian Date: Wed, 20 Feb 2002 03:49:06 +0000 (+0000) Subject: Add cursors outside transactions thread. X-Git-Tag: REL7_3~2094 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=9cfb55c55af0c6ef44cd0ca234662b4cb229aef9;p=postgresql Add cursors outside transactions thread. --- diff --git a/doc/TODO.detail/cursor b/doc/TODO.detail/cursor new file mode 100644 index 0000000000..c87c57476e --- /dev/null +++ b/doc/TODO.detail/cursor @@ -0,0 +1,530 @@ +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 +