--- /dev/null
+From pgsql-general-owner+M19848=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 10:36:36 2002
+Return-path: <pgsql-general-owner+M19848=candle.pha.pa.us=pgman@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <Inoue@tpf.co.jp>
+cc: Bruce Momjian <pgman@candle.pha.pa.us>,
+ Florian Wunderlich <fwunderlich@devbrain.de>, 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 <Inoue@tpf.co.jp>
+ 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 <tgl@sss.pgh.pa.us>
+Precedence: bulk
+Sender: pgsql-general-owner@postgresql.org
+Status: OR
+
+Hiroshi Inoue <Inoue@tpf.co.jp> 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: <pgsql-general-owner+M19849=candle.pha.pa.us=pgman@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <fwunderlich@devbrain.de>
+X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686)
+X-Accept-Language: en
+MIME-Version: 1.0
+To: Tom Lane <tgl@sss.pgh.pa.us>
+cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
+ 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 <Inoue@tpf.co.jp> 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: <pgsql-general-owner+M19851=candle.pha.pa.us=pgman@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <fwunderlich@devbrain.de>
+cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
+ 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 <fwunderlich@devbrain.de>
+ 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 <tgl@sss.pgh.pa.us>
+Precedence: bulk
+Sender: pgsql-general-owner@postgresql.org
+Status: OR
+
+Florian Wunderlich <fwunderlich@devbrain.de> 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: <Inoue@tpf.co.jp>
+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 <pgman@candle.pha.pa.us>; 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" <Inoue@tpf.co.jp>
+To: "Tom Lane" <tgl@sss.pgh.pa.us>
+cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
+ "Florian Wunderlich" <fwunderlich@devbrain.de>,
+ <pgsql-general@postgresql.org>
+Subject: RE: [GENERAL] persistent portals/cursors (between transactions)
+Date: Sat, 26 Jan 2002 01:57:54 +0900
+Message-ID: <EKEJJICOHDIEMGPNIFIJOELEGJAA.Inoue@tpf.co.jp>
+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 <Inoue@tpf.co.jp> 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: <pgsql-general-owner+M19852=candle.pha.pa.us=pgman@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <fwunderlich@devbrain.de>
+X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686)
+X-Accept-Language: en
+MIME-Version: 1.0
+To: Tom Lane <tgl@sss.pgh.pa.us>
+cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
+ 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: <pgsql-general-owner+M19855=candle.pha.pa.us=pgman@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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" <Inoue@tpf.co.jp>
+cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
+ "Florian Wunderlich" <fwunderlich@devbrain.de>,
+ pgsql-general@postgresql.org
+Subject: Re: [GENERAL] persistent portals/cursors (between transactions)
+In-Reply-To: <EKEJJICOHDIEMGPNIFIJOELEGJAA.Inoue@tpf.co.jp>
+References: <EKEJJICOHDIEMGPNIFIJOELEGJAA.Inoue@tpf.co.jp>
+Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
+ 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 <tgl@sss.pgh.pa.us>
+Precedence: bulk
+Sender: pgsql-general-owner@postgresql.org
+Status: OR
+
+"Hiroshi Inoue" <Inoue@tpf.co.jp> 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: <tgl@sss.pgh.pa.us>
+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 <pgman@candle.pha.pa.us>; 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 <fwunderlich@devbrain.de>
+cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
+ 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 <fwunderlich@devbrain.de>
+ 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 <tgl@sss.pgh.pa.us>
+Status: OR
+
+Florian Wunderlich <fwunderlich@devbrain.de> 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: <Inoue@tpf.co.jp>
+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 <pgman@candle.pha.pa.us>; 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" <Inoue@tpf.co.jp>
+To: "Florian Wunderlich" <fwunderlich@devbrain.de>
+cc: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us>,
+ <pgsql-general@postgresql.org>, "Jan Wieck" <janwieck@yahoo.com>
+Subject: RE: [GENERAL] persistent portals/cursors (between transactions)
+Date: Sat, 26 Jan 2002 02:23:26 +0900
+Message-ID: <EKEJJICOHDIEMGPNIFIJEELHGJAA.Inoue@tpf.co.jp>
+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: <pgsql-general-owner+M19860=candle.pha.pa.us=pgman@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <fwunderlich@devbrain.de>
+X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686)
+X-Accept-Language: en
+MIME-Version: 1.0
+To: Tom Lane <tgl@sss.pgh.pa.us>
+cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
+ 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
+
projects / postgresql / commitdiff