From pgsql-hackers-owner+M11649@postgresql.org Wed Aug 1 15:22:46 2001 Return-path: 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 ; 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 ; 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 ; Wed, 1 Aug 2001 12:04:31 -0700 Message-ID: <3705826352029646A3E91C53F7189E32016705@sectorbase2.sectorbase.com> From: "Mikheev, Vadim" To: "'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: 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 ; 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 ; 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 Message-ID: <200201231819.g0NIJ5i24508@candle.pha.pa.us> Subject: [HACKERS] Savepoints To: PostgreSQL-development 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: 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 ; 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 X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Momjian cc: PostgreSQL-development 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.