>
> regards, tom lane
+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: OR
+
+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+M11790@postgresql.org Sun Aug 5 14:41:34 2001
+Return-path: <pgsql-hackers-owner+M11790@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 f75IfXh25356
+ for <pgman@candle.pha.pa.us>; Sun, 5 Aug 2001 14:41:33 -0400 (EDT)
+Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
+ by postgresql.org (8.11.3/8.11.4) with SMTP id f75IfY644815;
+ Sun, 5 Aug 2001 14:41:34 -0400 (EDT)
+ (envelope-from pgsql-hackers-owner+M11790@postgresql.org)
+Received: from candle.pha.pa.us (candle.navpoint.com [162.33.245.46])
+ by postgresql.org (8.11.3/8.11.4) with ESMTP id f75IUs641174
+ for <pgsql-hackers@postgresql.org>; Sun, 5 Aug 2001 14:30:54 -0400 (EDT)
+ (envelope-from pgman@candle.pha.pa.us)
+Received: (from pgman@localhost)
+ by candle.pha.pa.us (8.10.1/8.10.1) id f75IUhM25071;
+ Sun, 5 Aug 2001 14:30:43 -0400 (EDT)
+From: Bruce Momjian <pgman@candle.pha.pa.us>
+Message-ID: <200108051830.f75IUhM25071@candle.pha.pa.us>
+Subject: Re: [HACKERS] Idea for nested transactions / savepoints
+In-Reply-To: <8173.997022088@sss.pgh.pa.us> "from Tom Lane at Aug 5, 2001 10:34:48
+ am"
+To: Tom Lane <tgl@sss.pgh.pa.us>
+Date: Sun, 5 Aug 2001 14:30:43 -0400 (EDT)
+cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
+X-Mailer: ELM [version 2.4ME+ PL90 (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
+
+> Bruce Momjian <pgman@candle.pha.pa.us> writes:
+> > My idea is that we not put UNDO information into WAL but keep a List of
+> > rel ids / tuple ids in the memory of each backend and do the undo inside
+> > the backend.
+>
+> The complaints about WAL size amount to "we don't have the disk space
+> to keep track of this, for long-running transactions". If it doesn't
+> fit on disk, how likely is it that it will fit in memory?
+
+Sure, we can put on the disk if that is better. I thought the problem
+with WAL undo is that you have to keep UNDO info around for all
+transactions that are older than the earliest transaction. So, if I
+start a nested transaction, and then sit at a prompt for 8 hours, all
+WAL logs are kept for 8 hours.
+
+We can create a WAL file for every backend, and record just the nested
+transaction information. In fact, once a nested transaction finishes,
+we don't need the info anymore. Certainly we don't need to flush these
+to disk.
+
+--
+ 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 pgman Sun Aug 5 21:16:32 2001
+Return-path: <pgman>
+Received: (from pgman@localhost)
+ by candle.pha.pa.us (8.10.1/8.10.1) id f761GWH11356;
+ Sun, 5 Aug 2001 21:16:32 -0400 (EDT)
+From: Bruce Momjian <pgman>
+Message-ID: <200108060116.f761GWH11356@candle.pha.pa.us>
+Subject: Re: [HACKERS] Idea for nested transactions / savepoints
+In-Reply-To: <200108051938.f75Jchi27522@candle.pha.pa.us> "from Bruce Momjian
+ at Aug 5, 2001 03:38:43 pm"
+To: Bruce Momjian <pgman@candle.pha.pa.us>
+Date: Sun, 5 Aug 2001 21:16:32 -0400 (EDT)
+cc: Tom Lane <tgl@sss.pgh.pa.us>,
+ PostgreSQL-development <pgsql-hackers@postgresql.org>
+X-Mailer: ELM [version 2.4ME+ PL90 (25)]
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Content-Type: text/plain; charset=US-ASCII
+Status: OR
+
+> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
+> > >> The complaints about WAL size amount to "we don't have the disk space
+> > >> to keep track of this, for long-running transactions". If it doesn't
+> > >> fit on disk, how likely is it that it will fit in memory?
+> >
+> > > Sure, we can put on the disk if that is better.
+> >
+> > I think you missed my point. Unless something can be done to make the
+> > log info a lot smaller than it is now, keeping it all around until
+> > transaction end is just not pleasant. Waving your hands and saying
+> > that we'll keep it in a different place doesn't affect the fundamental
+> > problem: if the transaction runs a long time, the log is too darn big.
+>
+> When you said long running, I thought you were concerned about long
+> running in duration, not large transaction. Long duration in one-WAL
+> setup would cause all transaction logs to be kept. Large transactions
+> are another issue.
+>
+> One solution may be to store just the relid if many tuples are modified
+> in the same table. If you stored the command counter for start/end of
+> the nested transaction, it would be possible to sequential scan the
+> table and undo all the affected tuples. Does that help? Again, I am
+> just throwing out ideas here, hoping something will catch.
+
+Actually, we need to keep around nested transaction UNDO information
+only until the nested transaction exits to the main transaction:
+
+ BEGIN WORK;
+ BEGIN WORK;
+ COMMIT;
+ -- we can throw away the UNDO here
+ BEGIN WORK;
+ BEGIN WORK;
+ ...
+ COMMIT
+ COMMIT;
+ -- we can throw away the UNDO here
+ COMMIT;
+
+We are using the outside transaction for our ACID capabilities, and just
+using UNDO for nested transaction capability.
+
+--
+ 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
+
projects / postgresql / commitdiff