mirror of https://github.com/postgres/postgres
Bruce Momjian
24 years ago
parent
fe3045f5a9
commit
9cfb55c55a
@ -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: <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 |
||||
|
||||
Loading…
Reference in new issue