mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-27 08:39:28 +08:00
Code Issues Packages Projects Releases Wiki Activity
6f4855842c
postgresql/doc/TODO.detail/cursor
Bruce Momjian 9cfb55c55a Add cursors outside transactions thread.
2002-02-20 03:49:06 +00:00

531 lines
25 KiB
Plaintext
Raw Blame History

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
Reference in New Issue View Git Blame Copy Permalink