+++ /dev/null
-From pgsql-hackers-owner+M11649@postgresql.org Wed Aug 1 15:22:46 2001
-Return-path: <pgsql-hackers-owner+M11649@postgresql.org>
-Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f71JMjN09768
- for <pgman@candle.pha.pa.us>; Wed, 1 Aug 2001 15:22:45 -0400 (EDT)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f71JMUf62338;
- Wed, 1 Aug 2001 15:22:30 -0400 (EDT)
- (envelope-from pgsql-hackers-owner+M11649@postgresql.org)
-Received: from sectorbase2.sectorbase.com (sectorbase2.sectorbase.com [63.88.121.62] (may be forged))
- by postgresql.org (8.11.3/8.11.1) with SMTP id f71J4df57086
- for <pgsql-hackers@postgresql.org>; Wed, 1 Aug 2001 15:04:40 -0400 (EDT)
- (envelope-from vmikheev@SECTORBASE.COM)
-Received: by sectorbase2.sectorbase.com with Internet Mail Service (5.5.2653.19)
- id <PG1LSSPZ>; Wed, 1 Aug 2001 12:04:31 -0700
-Message-ID: <3705826352029646A3E91C53F7189E32016705@sectorbase2.sectorbase.com>
-From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
-Subject: [HACKERS] Using POSIX mutex-es
-Date: Wed, 1 Aug 2001 12:04:24 -0700
-MIME-Version: 1.0
-X-Mailer: Internet Mail Service (5.5.2653.19)
-Content-Type: text/plain;
- charset="koi8-r"
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: RO
-
-1. Just changed
- TAS(lock) to pthread_mutex_trylock(lock)
- S_LOCK(lock) to pthread_mutex_lock(lock)
- S_UNLOCK(lock) to pthread_mutex_unlock(lock)
-(and S_INIT_LOCK to share mutex-es between processes).
-
-2. pgbench was initialized with scale 10.
- SUN WS 10 (512Mb), Solaris 2.6 (I'm unable to test on E4500 -:()
- -B 16384, wal_files 8, wal_buffers 256,
- checkpoint_segments 64, checkpoint_timeout 3600
- 50 clients x 100 transactions
- (after initialization DB dir was saved and before each test
- copyed back and vacuum-ed).
-
-3. No difference.
- Mutex version maybe 0.5-1 % faster (eg: 37.264238 tps vs 37.083339 tps).
-
-So - no gain, but no performance loss "from using pthread library"
-(I've also run tests with 1 client), at least on Solaris.
-
-And so - looks like we can use POSIX mutex-es and conditional variables
-(not semaphores; man pthread_cond_wait) and should implement light lmgr,
-probably with priority locking.
-
-Vadim
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
- (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
-
-From pgsql-hackers-owner+M18052=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 13:39:19 2002
-Return-path: <pgsql-hackers-owner+M18052=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 g0NIdIU26480
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 13:39:18 -0500 (EST)
-Received: (qmail 59371 invoked by alias); 23 Jan 2002 18:39:18 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 23 Jan 2002 18:39:18 -0000
-Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NIJ8l47400
- for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 13:19:08 -0500 (EST)
- (envelope-from pgman@candle.pha.pa.us)
-Received: (from pgman@localhost)
- by candle.pha.pa.us (8.11.6/8.10.1) id g0NIJ5i24508
- for pgsql-hackers@postgreSQL.org; Wed, 23 Jan 2002 13:19:05 -0500 (EST)
-From: Bruce Momjian <pgman@candle.pha.pa.us>
-Message-ID: <200201231819.g0NIJ5i24508@candle.pha.pa.us>
-Subject: [HACKERS] Savepoints
-To: PostgreSQL-development <pgsql-hackers@postgresql.org>
-Date: Wed, 23 Jan 2002 13:19:05 -0500 (EST)
-X-Mailer: ELM [version 2.4ME+ PL96 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: RO
-
-I have talked in the past about a possible implementation of
-savepoints/nested transactions. I would like to more formally outline
-my ideas below.
-
-We have talked about using WAL for such a purpose, but that requires WAL
-files to remain for the life of a transaction, which seems unacceptable.
-Other database systems do that, and it is a pain for administrators. I
-realized we could do some sort of WAL compaction, but that seems quite
-complex too.
-
-Basically, under my plan, WAL would be unchanged. WAL's function is
-crash recovery, and it would retain that. There would also be no
-on-disk changes. I would use the command counter in certain cases to
-identify savepoints.
-
-My idea is to keep savepoint undo information in a private area per
-backend, either in memory or on disk. We can either save the
-relid/tids of modified rows, or if there are too many, discard the
-saved ones and just remember the modified relids. On rollback to save
-point, either clear up the modified relid/tids, or sequential scan
-through the relid and clear up all the tuples that have our transaction
-id and have command counters that are part of the undo savepoint.
-
-It seems marking undo savepoint rows with a fixed aborted transaction id
-would be the easiest solution.
-
-Of course, we only remember modified rows when we are in savepoints, and
-only undo them when we rollback to a savepoint. Transaction processing
-remains the same.
-
-There is no reason for other backend to be able to see savepoint undo
-information, and keeping it private greatly simplifies the
-implementation.
-
---
- Bruce Momjian | http://candle.pha.pa.us
- pgman@candle.pha.pa.us | (610) 853-3000
- + If your life is a hard drive, | 830 Blythe Avenue
- + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://archives.postgresql.org
-
-From hstenger@adinet.com.uy Wed Jan 23 14:13:33 2002
-Return-path: <hstenger@adinet.com.uy>
-Received: from correo.adinet.com.uy (fecorreo01.adinet.com.uy [206.99.44.217])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0NJDWU29832
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 14:13:33 -0500 (EST)
-Received: from adinet.com.uy (200.61.76.155) by correo.adinet.com.uy (5.5.052) (authenticated as hstenger@adinet.com.uy)
- id 3C4DBC5C00017E9F; Wed, 23 Jan 2002 16:13:25 -0300
-Message-ID: <3C4F0BC0.5CFBB919@adinet.com.uy>
-Date: Wed, 23 Jan 2002 16:15:12 -0300
-From: Haroldo Stenger <hstenger@adinet.com.uy>
-X-Mailer: Mozilla 4.78 [en] (Win98; U)
-X-Accept-Language: en
-MIME-Version: 1.0
-To: Bruce Momjian <pgman@candle.pha.pa.us>
-cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
-Subject: Re: [HACKERS] Savepoints
-References: <200201231819.g0NIJ5i24508@candle.pha.pa.us>
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-Status: OR
-
-Bruce Momjian wrote:
->
-> Basically, under my plan, WAL would be unchanged. WAL's function is
-> crash recovery, and it would retain that. There would also be no
-> on-disk changes. I would use the command counter in certain cases to
-> identify savepoints.
-
-This is a pointer to the previous August thread, where your original proposal
-was posted, and some WAL/not WAL discussion took place. Just not to repeat the
-already mentioned points. Oh, it's google archive just for fun, and to not
-overload hub.org ;-)
-
-http://groups.google.com/groups?hl=en&threadm=200108050432.f754Wdo11696%40candle.pha.pa.us&rnum=1&prev=/groups%3Fhl%3Den%26selm%3D200108050432.f754Wdo11696%2540candle.pha.pa.us
-
-Regards,
-Haroldo.
-
-From vmikheev@SECTORBASE.COM Wed Jan 23 18:23:04 2002
-Return-path: <vmikheev@SECTORBASE.COM>
-Received: from sectorbase2.sectorbase.com ([66.106.163.120])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0NNN3U21442
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 18:23:04 -0500 (EST)
-Received: by sectorbase2.sectorbase.com with Internet Mail Service (5.5.2653.19)
- id <DKXVZ14S>; Wed, 23 Jan 2002 15:22:52 -0800
-Message-ID: <3705826352029646A3E91C53F7189E32518483@sectorbase2.sectorbase.com>
-From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>,
- PostgreSQL-development
- <pgsql-hackers@postgreSQL.org>
-Subject: RE: [HACKERS] Savepoints
-Date: Wed, 23 Jan 2002 15:22:42 -0800
-MIME-Version: 1.0
-X-Mailer: Internet Mail Service (5.5.2653.19)
-Content-Type: text/plain;
- charset="iso-8859-1"
-Status: ORr
-
-> I have talked in the past about a possible implementation of
-> savepoints/nested transactions. I would like to more formally outline
-> my ideas below.
-
-Well, I would like to do the same -:)
-
-> ...
-> There is no reason for other backend to be able to see savepoint undo
-> information, and keeping it private greatly simplifies the
-> implementation.
-
-Yes... and requires additional memory/disk space: we keep old records
-in data files and we'll store them again...
-
-How about: use overwriting smgr + put old records into rollback
-segments - RS - (you have to keep them somewhere till TX's running
-anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-changes and WAL will be used for RS/data files recovery).
-Something like what Oracle does.
-
-Vadim
-
-From pgsql-hackers-owner+M18085=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 20:15:02 2002
-Return-path: <pgsql-hackers-owner+M18085=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 g0O1F1U26461
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 20:15:02 -0500 (EST)
-Received: (qmail 92866 invoked by alias); 24 Jan 2002 01:14:59 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 24 Jan 2002 01:14:59 -0000
-Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0O18ml91949
- for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 20:08:50 -0500 (EST)
- (envelope-from pgman@candle.pha.pa.us)
-Received: (from pgman@localhost)
- by candle.pha.pa.us (8.11.6/8.10.1) id g0O18jV26044;
- Wed, 23 Jan 2002 20:08:45 -0500 (EST)
-From: Bruce Momjian <pgman@candle.pha.pa.us>
-Message-ID: <200201240108.g0O18jV26044@candle.pha.pa.us>
-Subject: Re: [HACKERS] Savepoints
-In-Reply-To: <3705826352029646A3E91C53F7189E32518483@sectorbase2.sectorbase.com>
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-Date: Wed, 23 Jan 2002 20:08:45 -0500 (EST)
-cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
-X-Mailer: ELM [version 2.4ME+ PL96 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-Mikheev, Vadim wrote:
-> > I have talked in the past about a possible implementation of
-> > savepoints/nested transactions. I would like to more formally outline
-> > my ideas below.
->
-> Well, I would like to do the same -:)
-
-Good.
-
-> > ...
-> > There is no reason for other backend to be able to see savepoint undo
-> > information, and keeping it private greatly simplifies the
-> > implementation.
->
-> Yes... and requires additional memory/disk space: we keep old records
-> in data files and we'll store them again...
-
-I was suggesting keeping only relid/tid or in some cases only relid.
-Seems like one or the other will fit all needs: relid/tid for update of
-a few rows, relid for many rows updated in the same table. I saw no
-need to store the actual data.
-
-> How about: use overwriting smgr + put old records into rollback
-> segments - RS - (you have to keep them somewhere till TX's running
-> anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> changes and WAL will be used for RS/data files recovery).
-> Something like what Oracle does.
-
-Why record the old data rows rather than the tids? While the
-transaction is running, the rows can't be moved anyway. Also, why store
-them in a shared area. That has additional requirements because one old
-transaction can require all transactions to keep their stuff around.
-Why not just make it a private data file for each backend?
-
---
- Bruce Momjian | http://candle.pha.pa.us
- pgman@candle.pha.pa.us | (610) 853-3000
- + If your life is a hard drive, | 830 Blythe Avenue
- + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
----------------------------(end of broadcast)---------------------------
-TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
-
-From pgsql-hackers-owner+M18086=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 20:25:47 2002
-Return-path: <pgsql-hackers-owner+M18086=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 g0O1PkU26964
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 20:25:47 -0500 (EST)
-Received: (qmail 94878 invoked by alias); 24 Jan 2002 01:25:44 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 24 Jan 2002 01:25:44 -0000
-Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0O1L1l94075
- for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 20:21:01 -0500 (EST)
- (envelope-from pgman@candle.pha.pa.us)
-Received: (from pgman@localhost)
- by candle.pha.pa.us (8.11.6/8.10.1) id g0O1Kwm26748;
- Wed, 23 Jan 2002 20:20:58 -0500 (EST)
-From: Bruce Momjian <pgman@candle.pha.pa.us>
-Message-ID: <200201240120.g0O1Kwm26748@candle.pha.pa.us>
-Subject: Re: [HACKERS] Savepoints
-In-Reply-To: <3705826352029646A3E91C53F7189E32518483@sectorbase2.sectorbase.com>
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-Date: Wed, 23 Jan 2002 20:20:58 -0500 (EST)
-cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
-X-Mailer: ELM [version 2.4ME+ PL96 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-> > There is no reason for other backend to be able to see savepoint undo
-> > information, and keeping it private greatly simplifies the
-> > implementation.
->
-> Yes... and requires additional memory/disk space: we keep old records
-> in data files and we'll store them again...
->
-> How about: use overwriting smgr + put old records into rollback
-> segments - RS - (you have to keep them somewhere till TX's running
-> anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> changes and WAL will be used for RS/data files recovery).
-> Something like what Oracle does.
-
-I am sorry. I see what you are saying now. I missed the words
-"overwriting smgr". You are suggesting going to an overwriting storage
-manager. Is this to be done only because of savepoints. Doesn't seem
-worth it when I have a possible solution without such a drastic change.
-Also, overwriting storage manager will require MVCC to read through
-there to get accurate MVCC visibility, right?
-
---
- Bruce Momjian | http://candle.pha.pa.us
- pgman@candle.pha.pa.us | (610) 853-3000
- + If your life is a hard drive, | 830 Blythe Avenue
- + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
----------------------------(end of broadcast)---------------------------
-TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
-
-From vmikheev@SECTORBASE.COM Wed Jan 23 21:03:29 2002
-Return-path: <vmikheev@SECTORBASE.COM>
-Received: from sectorbase2.sectorbase.com ([66.106.163.120])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0O23TU28813
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 21:03:29 -0500 (EST)
-Received: by sectorbase2.sectorbase.com with Internet Mail Service (5.5.2653.19)
- id <DKXVZFBY>; Wed, 23 Jan 2002 18:03:18 -0800
-Message-ID: <3705826352029646A3E91C53F7189E32518487@sectorbase2.sectorbase.com>
-From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>
-cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
-Subject: RE: [HACKERS] Savepoints
-Date: Wed, 23 Jan 2002 18:03:11 -0800
-MIME-Version: 1.0
-X-Mailer: Internet Mail Service (5.5.2653.19)
-Content-Type: text/plain;
- charset="iso-8859-1"
-Status: ORr
-
-> > How about: use overwriting smgr + put old records into rollback
-> > segments - RS - (you have to keep them somewhere till TX's running
-> > anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> > changes and WAL will be used for RS/data files recovery).
-> > Something like what Oracle does.
->
-> I am sorry. I see what you are saying now. I missed the words
-
-And I'm sorry for missing your notes about storing relid+tid only.
-
-> "overwriting smgr". You are suggesting going to an overwriting
-> storage manager. Is this to be done only because of savepoints.
-
-No. One point I made a few monthes ago (and never got objections)
-is - why to keep old data in data files sooooo long?
-Imagine long running TX (eg pg_dump). Why other TX-s must read
-again and again completely useless (for them) old data we keep
-for pg_dump?
-
-> Doesn't seem worth it when I have a possible solution without
-> such a drastic change.
-> Also, overwriting storage manager will require MVCC to read
-> through there to get accurate MVCC visibility, right?
-
-Right... just like now non-overwriting smgr requires *ALL*
-TX-s to read old data in data files. But with overwriting smgr
-TX will read RS only when it is required and as far (much) as
-it is required.
-
-Simple solutions are not always the best ones.
-Compare Oracle and InterBase. Both have MVCC.
-Smgr-s are different. What RDBMS is more cool?
-Why doesn't Oracle use more simple non-overwriting smgr
-(as InterBase... and we do)?
-
-Vadim
-
-From dhogaza@pacifier.com Wed Jan 23 21:05:37 2002
-Return-path: <dhogaza@pacifier.com>
-Received: from comet.pacifier.com ([199.2.117.155])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0O25bU28962
- for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 21:05:37 -0500 (EST)
-Received: from pacifier.com (dsl-dhogaza.pacifier.net [207.202.226.68])
- by comet.pacifier.com (8.11.2/8.11.1) with ESMTP id g0O24qX29917;
- Wed, 23 Jan 2002 18:04:52 -0800 (PST)
-Message-ID: <3C4F6BF0.2010406@pacifier.com>
-Date: Wed, 23 Jan 2002 18:05:36 -0800
-From: Don Baccus <dhogaza@pacifier.com>
-User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
-X-Accept-Language: en-us
-MIME-Version: 1.0
-To: Bruce Momjian <pgman@candle.pha.pa.us>
-cc: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>,
- PostgreSQL-development <pgsql-hackers@postgresql.org>
-Subject: Re: [HACKERS] Savepoints
-References: <200201240120.g0O1Kwm26748@candle.pha.pa.us>
-Content-Type: text/plain; charset=us-ascii; format=flowed
-Content-Transfer-Encoding: 7bit
-Status: OR
-
-Bruce Momjian wrote:
-
-
-> I am sorry. I see what you are saying now. I missed the words
-> "overwriting smgr". You are suggesting going to an overwriting storage
-> manager.
-
-
-Overwriting storage managers don't suffer from unbounded growth of
-datafiles until garbage collection (vacuum) is performed. In fact,
-there's no need for a vacuum-style utility. The rollback segments only
-need to keep around enough past history to rollback transactions that
-are executing.
-
-Of course, then the size of your transactions are limited by the size of
-your rollback segments, which in Oracle are fixed in length when you
-build your database (there are ways to change this when you figure out
-that you didn't pick a good number when creating it).
-
- >Is this to be done only because of savepoints.
-
-Not in traditional storage managers such as Oracle uses. The complexity
-of managing visibility and the like are traded off against the fact that
-you're not stuck ever needing to garbage collect a database that
-occupies a roomful of disks.
-
-It's a trade-off. PG's current storage manager seems to work awfully
-well in a lot of common database scenarios, and Tom's new vacuum is
-meant to help mitigate against the drawbacks. But overwriting storage
-managers certainly have their advantages, too.
-
- > Doesn't seem
-
-> worth it when I have a possible solution without such a drastic change.
-> Also, overwriting storage manager will require MVCC to read through
-> there to get accurate MVCC visibility, right?
-
-
-Yep...
-
---
-Don Baccus
-Portland, OR
-http://donb.photo.net, http://birdnotes.net, http://openacs.org
-
-
-From Inoue@tpf.co.jp Thu Jan 24 11:34:48 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 g0OGYjU23980
- for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 11:34:47 -0500 (EST)
-Received: from mcadnote1 (ppm132.noc.fukui.nsk.ne.jp [61.198.95.32])
- by p2272.nsk.ne.jp (8.9.3/3.7W-20000722) with SMTP id BAA12147;
- Fri, 25 Jan 2002 01:34:24 +0900 (JST)
-From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>,
- "'Bruce Momjian'" <pgman@candle.pha.pa.us>
-Subject: RE: [HACKERS] Savepoints
-Date: Fri, 25 Jan 2002 01:34:29 +0900
-Message-ID: <EKEJJICOHDIEMGPNIFIJKEFBGJAA.Inoue@tpf.co.jp>
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-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: <3705826352029646A3E91C53F7189E32518483@sectorbase2.sectorbase.com>
-X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
-Importance: Normal
-Status: OR
-
-> -----Original Message-----
-> From: Mikheev, Vadim
->
-> How about: use overwriting smgr + put old records into rollback
-> segments - RS - (you have to keep them somewhere till TX's running
-> anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> changes and WAL will be used for RS/data files recovery).
-> Something like what Oracle does.
-
-As long as we use no overwriting manager
-1) Rollback(data) isn't needed in case of a db crash.
-2) Rollback(data) isn't needed to cancal a transaction entirely.
-3) We don't need to mind the transaction size so much.
-
-We can't use the db any longer if a REDO recovery fails now.
-Under overwriting smgr we can't use the db any longer either
-if rollback fails. How could PG be not less reliable than now ?
-
-regards,
-Hiroshi Inoue
-
-From pgsql-hackers-owner+M18123=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 14:15:11 2002
-Return-path: <pgsql-hackers-owner+M18123=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 g0OJFAU12547
- for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 14:15:10 -0500 (EST)
-Received: (qmail 43413 invoked by alias); 24 Jan 2002 19:13:48 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 24 Jan 2002 19:13:48 -0000
-Received: from sectorbase2.sectorbase.com ([66.106.163.120])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0OJC4l42011
- for <pgsql-hackers@postgreSQL.org>; Thu, 24 Jan 2002 14:12:04 -0500 (EST)
- (envelope-from vmikheev@SECTORBASE.COM)
-Received: by sectorbase2.sectorbase.com with Internet Mail Service (5.5.2653.19)
- id <DKXVZF9P>; Thu, 24 Jan 2002 11:11:54 -0800
-Message-ID: <3705826352029646A3E91C53F7189E3251848B@sectorbase2.sectorbase.com>
-From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-To: "'Hiroshi Inoue'" <Inoue@tpf.co.jp>
-cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
- "'Bruce Momjian'"
- <pgman@candle.pha.pa.us>
-Subject: Re: [HACKERS] Savepoints
-Date: Thu, 24 Jan 2002 11:11:52 -0800
-MIME-Version: 1.0
-X-Mailer: Internet Mail Service (5.5.2653.19)
-Content-Type: text/plain;
- charset="iso-8859-1"
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-> > How about: use overwriting smgr + put old records into rollback
-> > segments - RS - (you have to keep them somewhere till TX's running
-> > anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> > changes and WAL will be used for RS/data files recovery).
-> > Something like what Oracle does.
->
-> As long as we use no overwriting manager
-> 1) Rollback(data) isn't needed in case of a db crash.
-> 2) Rollback(data) isn't needed to cancal a transaction entirely.
-
--1) But vacuum must read a huge amount of data to remove dirt.
--2) But TX-s must read data they are not interested at all.
-
-> 3) We don't need to mind the transaction size so much.
-
--3) The same with overwriting smgr and WAL used *only as REDO log*:
-we are not required to keep WAL files for duration of transaction
-- as soon as server knows that changes logged in some WAL file
-applied to data files and RS on disk (and archived, for WAL-based
-BAR) that file may be reused/removed. Old data will still occupy
-space in RS but their space in data files will be available
-for reuse.
-
-> We can't use the db any longer if a REDO recovery fails now.
-
-Reset WAL and use/dump it. Annoying? Agreed. Fix bugs and/or
-use good RAM - whatever caused problem with restart.
-
-> Under overwriting smgr we can't use the db any longer either
-> if rollback fails.
-
-Why should it fail? Bugs? Fix them.
-
-> How could PG be not less reliable than now ?
-
-Is today' RG more reliable than Oracle, Informix, DB2?
-
-Vadim
-
----------------------------(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 pgsql-hackers-owner+M18125=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 14:23:42 2002
-Return-path: <pgsql-hackers-owner+M18125=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 g0OJNfU13481
- for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 14:23:42 -0500 (EST)
-Received: (qmail 49604 invoked by alias); 24 Jan 2002 19:23:40 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 24 Jan 2002 19:23:40 -0000
-Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0OJMTl48885
- for <pgsql-hackers@postgreSQL.org>; Thu, 24 Jan 2002 14:22:29 -0500 (EST)
- (envelope-from pgman@candle.pha.pa.us)
-Received: (from pgman@localhost)
- by candle.pha.pa.us (8.11.6/8.10.1) id g0OJMJf13378;
- Thu, 24 Jan 2002 14:22:19 -0500 (EST)
-From: Bruce Momjian <pgman@candle.pha.pa.us>
-Message-ID: <200201241922.g0OJMJf13378@candle.pha.pa.us>
-Subject: Re: [HACKERS] Savepoints
-In-Reply-To: <3705826352029646A3E91C53F7189E32518487@sectorbase2.sectorbase.com>
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-Date: Thu, 24 Jan 2002 14:22:19 -0500 (EST)
-cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
-X-Mailer: ELM [version 2.4ME+ PL96 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-
-OK, I have had time to think about this, and I think I can put the two
-proposals into perspective. I will use Vadim's terminology.
-
-In our current setup, rollback/undo data is kept in the same file as our
-live data. This data is used for two purposes, one, for rollback of
-transactions, and perhaps subtransactions in the future, and second, for
-MVCC visibility for backends making changes.
-
-So, it seems the real question is whether a database modification should
-write the old data into a separate rollback segment and modify the heap
-data, or just create a new row and require the old row to be removed
-later by vacuum.
-
-Let's look at this behavior without MVCC. In such cases, if someone
-tries to read a modified row, it will block and wait for the modifying
-backend to commit or rollback, when it will then continue. In such
-cases, there is no reason for the waiting transaction to read the old
-data in the redo segment because it can't continue anyway.
-
-Now, with MVCC, the backend has to read through the redo segment to get
-the original data value for that row.
-
-Now, while rollback segments do help with cleaning out old UPDATE rows,
-how does it improve DELETE performance? Seems it would just mark it as
-expired like we do now.
-
-One objection I always had to redo segments was that if I start a
-transaction in the morning and walk away, none of the redo segments can
-be recycled. I was going to ask if we can force some type of redo
-segment compaction to keep old active rows and delete rows no longer
-visible to any transaction. However, I now realize that our VACUUM has
-the same problem. Tuples with XID >= GetOldestXmin() are not recycled,
-meaning we have this problem in our current implementation too. (I
-wonder if our vacuum could be smarter about knowing which rows are
-visible, perhaps by creating a sorted list of xid's and doing a binary
-search on the list to determine visibility.)
-
-So, I guess the issue is, do we want to keep redo information in the
-main table, or split it out into redo segments. Certainly we have to
-eliminate the Oracle restrictions that redo segment size is fixed at
-install time.
-
-The advantages of a redo segment is that hopefully we don't have
-transactions reading through irrelevant undo information. The
-disadvantage is that we now have redo information grouped into table
-files where a sequential scan can be performed. (Index scans of redo
-info are a performance problem currently.) We would have to somehow
-efficiently access redo information grouped into the redo segments.
-Perhaps a hash based in relid would help here. Another disadvantage is
-concurrency. When we start modifying heap data in place, we have to
-prevent other backends from seeing that modification while we move the
-old data to the redo segment.
-
-I guess my feeling is that if we can get vacuum to happen automatically,
-how is our current non-overwriting storage manager different from redo
-segments?
-
-One big advantage of redo segments would be that right now, if someone
-updates a row repeatedly, there are lots of heap versions of the row
-that are difficult to shrink in the table, while if they are in the redo
-segments, we can more efficiently remove them, and there is only on heap
-row.
-
-How is recovery handled with rollback segments? Do we write old and new
-data to WAL? We just write new data to WAL now, right? Do we fsync
-rollback segments?
-
-Have I outlined this accurately?
-
----------------------------------------------------------------------------
-
-Mikheev, Vadim wrote:
-> > > How about: use overwriting smgr + put old records into rollback
-> > > segments - RS - (you have to keep them somewhere till TX's running
-> > > anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> > > changes and WAL will be used for RS/data files recovery).
-> > > Something like what Oracle does.
-> >
-> > I am sorry. I see what you are saying now. I missed the words
->
-> And I'm sorry for missing your notes about storing relid+tid only.
->
-> > "overwriting smgr". You are suggesting going to an overwriting
-> > storage manager. Is this to be done only because of savepoints.
->
-> No. One point I made a few monthes ago (and never got objections)
-> is - why to keep old data in data files sooooo long?
-> Imagine long running TX (eg pg_dump). Why other TX-s must read
-> again and again completely useless (for them) old data we keep
-> for pg_dump?
->
-> > Doesn't seem worth it when I have a possible solution without
-> > such a drastic change.
-> > Also, overwriting storage manager will require MVCC to read
-> > through there to get accurate MVCC visibility, right?
->
-> Right... just like now non-overwriting smgr requires *ALL*
-> TX-s to read old data in data files. But with overwriting smgr
-> TX will read RS only when it is required and as far (much) as
-> it is required.
->
-> Simple solutions are not always the best ones.
-> Compare Oracle and InterBase. Both have MVCC.
-> Smgr-s are different. What RDBMS is more cool?
-> Why doesn't Oracle use more simple non-overwriting smgr
-> (as InterBase... and we do)?
->
-> Vadim
->
-
---
- Bruce Momjian | http://candle.pha.pa.us
- pgman@candle.pha.pa.us | (610) 853-3000
- + If your life is a hard drive, | 830 Blythe Avenue
- + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
- (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
-
-From pgsql-hackers-owner+M18141=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 19:43:38 2002
-Return-path: <pgsql-hackers-owner+M18141=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 g0P0hbU15026
- for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 19:43:38 -0500 (EST)
-Received: (qmail 28642 invoked by alias); 25 Jan 2002 00:43:24 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 25 Jan 2002 00:43:24 -0000
-Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
- by postgresql.org (8.11.3/8.11.4) with SMTP id g0P0YIl27208
- for <pgsql-hackers@postgreSQL.org>; Thu, 24 Jan 2002 19:34:18 -0500 (EST)
- (envelope-from Inoue@tpf.co.jp)
-Received: (qmail 3661 invoked from network); 25 Jan 2002 00:34:19 -0000
-Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
- by sd2.tpf-fw-c.co.jp with SMTP; 25 Jan 2002 00:34:19 -0000
-Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
- by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id JAA00756;
- Fri, 25 Jan 2002 09:34:18 +0900 (JST)
-Message-ID: <3C50A807.32A29E09@tpf.co.jp>
-Date: Fri, 25 Jan 2002 09:34:15 +0900
-From: Hiroshi Inoue <Inoue@tpf.co.jp>
-X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
-X-Accept-Language: ja
-MIME-Version: 1.0
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
- "'Bruce Momjian'" <pgman@candle.pha.pa.us>
-Subject: Re: [HACKERS] Savepoints
-References: <3705826352029646A3E91C53F7189E3251848B@sectorbase2.sectorbase.com>
-Content-Type: text/plain; charset=iso-2022-jp
-Content-Transfer-Encoding: 7bit
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-"Mikheev, Vadim" wrote:
->
-> > > How about: use overwriting smgr + put old records into rollback
-> > > segments - RS - (you have to keep them somewhere till TX's running
-> > > anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> > > changes and WAL will be used for RS/data files recovery).
-> > > Something like what Oracle does.
-> >
-> > As long as we use no overwriting manager
-> > 1) Rollback(data) isn't needed in case of a db crash.
-> > 2) Rollback(data) isn't needed to cancal a transaction entirely.
->
-> -1) But vacuum must read a huge amount of data to remove dirt.
-> -2) But TX-s must read data they are not interested at all.
->
-> > 3) We don't need to mind the transaction size so much.
->
-> -3) The same with overwriting smgr and WAL used *only as REDO log*:
-
-The larger RS becomes the longer it would take time to cancel
-the transaction whereas it is executed in a momemnt under no
-overwriting smgr and for example if RS exhausted all disk space
-is PG really safe ? Other backends would also fail because they
-couldn't write RS any mode. Many transactions would execute
-UNDO operations simultaneously but there's no space to write
-WALs (UNDO operations must be written to WAL also) and PG
-system would abort. And could PG restart under such situations ?
-Even though there's a way to recover from the situation, I
-think we should avoid such dangerous situations from the
-first. Basically recovery operations should never fail.
-
->
-> > We can't use the db any longer if a REDO recovery fails now.
->
-> Reset WAL and use/dump it. Annoying? Agreed. Fix bugs and/or
-> use good RAM - whatever caused problem with restart.
-
-As I already mentioned recovery operations should never fail.
->
-> > Under overwriting smgr we can't use the db any longer either
-> > if rollback fails.
->
-> Why should it fail? Bugs? Fix them.
-
-Rollback operations are executed much more often than
-REDO recovery and it is hard to fix such bugs once PG
-was released. Most people in such troubles have no
-time to persue the cause. In reality I replied to the
-PG restart troubles twice (with --wal-debug and pg_resetxlog
-suggestions ) in Japan but got no further replies.
-
->
-> > How could PG be not less reliable than now ?
->
-> Is today' RG more reliable than Oracle, Informix, DB2?
-
-I have never been and would never be optiomistic
-about recovery. Is 7.1 more reliable than 7.0 from the
-recovery POV ? I see no reason why overwriting smgr is
-more relaible than no overwriting smgr as for recovery.
-
-regards,
-Hiroshi Inoue
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://archives.postgresql.org
-
-From ZeugswetterA@spardat.at Fri Jan 25 09:21:40 2002
-Return-path: <ZeugswetterA@spardat.at>
-Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PELde10640
- for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 09:21:39 -0500 (EST)
-Received: from m01x1.s-mxs.net [10.3.55.201]
- by smxsat1.smxs.net
- with XWall v3.18f ;
- Fri, 25 Jan 2002 15:22:51 +0100
-Received: from m0103.s-mxs.net [10.3.55.3]
- by m01x1.s-mxs.net
- with XWall v3.18a ;
- Fri, 25 Jan 2002 15:21:23 +0100
-Received: from m0114.s-mxs.net ([10.3.55.14]) by m0103.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
- Fri, 25 Jan 2002 15:21:22 +0100
-X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
-content-class: urn:content-classes:message
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Subject: RE: [HACKERS] Savepoints
-Date: Fri, 25 Jan 2002 15:21:22 +0100
-Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA42128DE@m0114.s-mxs.net>
-Thread-Topic: [HACKERS] Savepoints
-Thread-Index: AcGkZ8SMKn//UUTjS3mi+qC7+gZAwwBQ4YMA
-From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>,
- "Bruce Momjian" <pgman@candle.pha.pa.us>,
- "PostgreSQL-development" <pgsql-hackers@postgresql.org>
-X-OriginalArrivalTime: 25 Jan 2002 14:21:22.0648 (UTC) FILETIME=[9090BD80:01C1A5AB]
-Content-Transfer-Encoding: 8bit
-X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id g0PELde10640
-Status: OR
-
-Vadim wrote:
-> How about: use overwriting smgr + put old records into rollback
-> segments - RS - (you have to keep them somewhere till TX's running
-> anyway) + use WAL only as REDO log (RS will be used to rollback TX'
-> changes and WAL will be used for RS/data files recovery).
-> Something like what Oracle does.
-
-We have all the info we need in WAL and in the old rows,
-why would you want to write them to RS ?
-You only need RS for overwriting smgr.
-
-Andreas
-
-From pgsql-hackers-owner+M18209=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 16:14:02 2002
-Return-path: <pgsql-hackers-owner+M18209=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 g0PLE1e19182
- for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 16:14:01 -0500 (EST)
-Received: (qmail 85111 invoked by alias); 25 Jan 2002 21:13:59 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 25 Jan 2002 21:13:59 -0000
-Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PL48l79366
- for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 16:04:09 -0500 (EST)
- (envelope-from ZeugswetterA@spardat.at)
-Received: from m01x1.s-mxs.net [10.3.55.201]
- by smxsat1.smxs.net
- with XWall v3.18f ;
- Fri, 25 Jan 2002 22:05:21 +0100
-Received: from m0102.s-mxs.net [10.3.55.2]
- by m01x1.s-mxs.net
- with XWall v3.18a ;
- Fri, 25 Jan 2002 22:03:54 +0100
-Received: from m0114.s-mxs.net ([10.3.55.14]) by m0102.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
- Fri, 25 Jan 2002 22:03:53 +0100
-X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
-content-class: urn:content-classes:message
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Subject: Re: [HACKERS] Savepoints
-Date: Fri, 25 Jan 2002 22:03:53 +0100
-Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C4@m0114.s-mxs.net>
-Thread-Topic: [HACKERS] Savepoints
-Thread-Index: AcGlDMGVwSWndt4kT1C7QhclLvQPWgA1arbw
-From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
-To: "Bruce Momjian" <pgman@candle.pha.pa.us>,
- "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
-X-OriginalArrivalTime: 25 Jan 2002 21:03:53.0685 (UTC) FILETIME=[CBB48850:01C1A5E3]
-Content-Transfer-Encoding: 8bit
-X-MIME-Autoconverted: from quoted-printable to 8bit by postgresql.org id g0PLDAm83732
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: ORr
-
-
-> Now, with MVCC, the backend has to read through the redo segment to get
-
-You mean rollback segment, but ...
-
-> the original data value for that row.
-
-Will only need to be looked up if the row is currently beeing modified by
-a not yet comitted txn (at least in the default read committed mode)
-
->
-> Now, while rollback segments do help with cleaning out old UPDATE rows,
-> how does it improve DELETE performance? Seems it would just mark it as
-> expired like we do now.
-
-delete would probably be:
-1. mark original deleted and write whole row to RS
-
-I don't think you would like to mix looking up deleted rows in heap
-but updated rows in RS
-
-Andreas
-
-PS: not that I like overwrite with MVCC now
-If you think of VACUUM as garbage collection PG is highly trendy with
-the non-overwriting smgr.
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-From pgsql-hackers-owner+M18211=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 16:53:45 2002
-Return-path: <pgsql-hackers-owner+M18211=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 g0PLrie22174
- for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 16:53:44 -0500 (EST)
-Received: (qmail 96831 invoked by alias); 25 Jan 2002 21:53:43 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 25 Jan 2002 21:53:43 -0000
-Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PLpRl96298
- for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 16:51:27 -0500 (EST)
- (envelope-from ZeugswetterA@spardat.at)
-Received: from m01x1.s-mxs.net [10.3.55.201]
- by smxsat1.smxs.net
- with XWall v3.18f ;
- Fri, 25 Jan 2002 22:52:54 +0100
-Received: from m0103.s-mxs.net [10.3.55.3]
- by m01x1.s-mxs.net
- with XWall v3.18a ;
- Fri, 25 Jan 2002 22:51:25 +0100
-Received: from m0114.s-mxs.net ([10.3.55.14]) by m0103.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
- Fri, 25 Jan 2002 22:51:25 +0100
-X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
-content-class: urn:content-classes:message
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Subject: Re: [HACKERS] Savepoints
-Date: Fri, 25 Jan 2002 22:51:24 +0100
-Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C5@m0114.s-mxs.net>
-Thread-Topic: [HACKERS] Savepoints
-Thread-Index: AcGlznYKFcqoYpMnSlGQHhQuEf6LuAAGpxnQ
-From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
-To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
-cc: <pgsql-hackers@postgresql.org>
-X-OriginalArrivalTime: 25 Jan 2002 21:51:25.0008 (UTC) FILETIME=[6F39E500:01C1A5EA]
-Content-Transfer-Encoding: 8bit
-X-MIME-Autoconverted: from quoted-printable to 8bit by postgresql.org id g0PLrP196418
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-
-> > > How about: use overwriting smgr + put old records into rollback
-> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-> > > segments - RS - (you have to keep them somewhere till TX's running
-> > > anyway) + use WAL only as REDO log (RS will be used to
-> rollback TX'
-> > > changes and WAL will be used for RS/data files recovery).
-> > > Something like what Oracle does.
-> >
-> > We have all the info we need in WAL and in the old rows,
-> > why would you want to write them to RS ?
-> > You only need RS for overwriting smgr.
->
-> This is what I'm saying - implement Overwriting smgr...
-
-Yes I am sorry, I am catching up on email and had not read Bruce's
-comment (nor yours correctly) :-(
-
-I was also long in the pro overwriting camp, because I am used to
-non MVCC dbs like DB/2 and Informix. (which I like very much)
-But I am starting to doubt that overwriting is really so good for
-an MVCC db. And I don't think PG wants to switch to non MVCC :-)
-
-Imho it would only need a much more aggressive VACUUM backend.
-(aka garbage collector :-) Maybe It could be designed to sniff the
-redo log (buffer) to get a hint at what to actually clean out next.
-
-Andreas
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-From pgsql-hackers-owner+M18218=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 19:14:24 2002
-Return-path: <pgsql-hackers-owner+M18218=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 g0Q0ENe03543
- for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 19:14:23 -0500 (EST)
-Received: (qmail 22482 invoked by alias); 26 Jan 2002 00:13:55 -0000
-Received: from unknown (HELO postgresql.org) (64.49.215.8)
- by www.postgresql.org with SMTP; 26 Jan 2002 00:13:55 -0000
-Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
- by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PNw1l20714
- for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 18:58:01 -0500 (EST)
- (envelope-from pgman@candle.pha.pa.us)
-Received: (from pgman@localhost)
- by candle.pha.pa.us (8.11.6/8.10.1) id g0PNvoL02515;
- Fri, 25 Jan 2002 18:57:50 -0500 (EST)
-From: Bruce Momjian <pgman@candle.pha.pa.us>
-Message-ID: <200201252357.g0PNvoL02515@candle.pha.pa.us>
-Subject: Re: [HACKERS] Savepoints
-In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C4@m0114.s-mxs.net>
-To: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>
-Date: Fri, 25 Jan 2002 18:57:50 -0500 (EST)
-cc: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>,
- PostgreSQL-development <pgsql-hackers@postgresql.org>
-X-Mailer: ELM [version 2.4ME+ PL96 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-Zeugswetter Andreas SB SD wrote:
->
-> > Now, with MVCC, the backend has to read through the redo segment to get
->
-> You mean rollback segment, but ...
-
-
-Sorry, yes. I get redo/undo/rollback mixed up sometimes. :-)
-
-> > the original data value for that row.
->
-> Will only need to be looked up if the row is currently beeing modified by
-> a not yet comitted txn (at least in the default read committed mode)
-
-Uh, not really. The transaction may have completed after my transaction
-started, meaning even though it looks like it is committed, to me, it is
-not visible. Most MVCC visibility will require undo lookup.
-
->
-> >
-> > Now, while rollback segments do help with cleaning out old UPDATE rows,
-> > how does it improve DELETE performance? Seems it would just mark it as
-> > expired like we do now.
->
-> delete would probably be:
-> 1. mark original deleted and write whole row to RS
->
-> I don't think you would like to mix looking up deleted rows in heap
-> but updated rows in RS
-
-Yes, so really the overwriting is only a big win for UPDATE. Right now,
-UPDATE is DELETE/INSERT, and that DELETE makes MVCC happy. :-)
-
-My whole goal was to simplify this so we can see the differences.
-
-
-> PS: not that I like overwrite with MVCC now
-> If you think of VACUUM as garbage collection PG is highly trendy with
-> the non-overwriting smgr.
-
-Yes, that is basically what it is now, a garbage collector that collects
-in heap rather than in undo.
-
---
- Bruce Momjian | http://candle.pha.pa.us
- pgman@candle.pha.pa.us | (610) 853-3000
- + If your life is a hard drive, | 830 Blythe Avenue
- + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
----------------------------(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 pgman Wed Jan 23 10:36:13 2002
-Subject: Savepoints
-To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
-Date: Wed, 23 Jan 2002 13:19:05 -0500 (EST)
-X-Mailer: ELM [version 2.4ME+ PL96 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Content-Length: 1829
-Status: OR
-
-I have talked in the past about a possible implementation of
-savepoints/nested transactions. I would like to more formally outline
-my ideas below.
-
-We have talked about using WAL for such a purpose, but that requires WAL
-files to remain for the life of a transaction, which seems unacceptable.
-Other database systems do that, and it is a pain for administrators. I
-realized we could do some sort of WAL compaction, but that seems quite
-complex too.
-
-Basically, under my plan, WAL would be unchanged. WAL's function is
-crash recovery, and it would retain that. There would also be no
-on-disk changes. I would use the command counter in certain cases to
-identify savepoints.
-
-My idea is to keep savepoint undo information in a private area per
-backend, either in memory or on disk. We can either save the
-relid/tids of modified rows, or if there are too many, discard the
-saved ones and just remember the modified relids. On rollback to save
-point, either clear up the modified relid/tids, or sequential scan
-through the relid and clear up all the tuples that have our transaction
-id and have command counters that are part of the undo savepoint.
-
-It seems marking undo savepoint rows with a fixed aborted transaction id
-would be the easiest solution.
-
-Of course, we only remember modified rows when we are in savepoints, and
-only undo them when we rollback to a savepoint. Transaction processing
-remains the same.
-
-There is no reason for other backend to be able to see savepoint undo
-information, and keeping it private greatly simplifies the
-implementation.
-
---
- Bruce Momjian | http://candle.pha.pa.us
- pgman@candle.pha.pa.us | (610) 853-3000
- + If your life is a hard drive, | 830 Blythe Avenue
- + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
OSDN Git Service
