Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL internals and implementation of transactions

From: Artur Pietruk <arturp(at)plukwa(dot)net>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: PostgreSQL internals and implementation of transactions
Date: 2004-12-20 22:42:09
Message-ID: 20041220224209.GL2149@plukwa.net (view raw or flat)
Thread:
Lists: pgsql-admin
Hi again, 

	Is there any updated info available on latest releases. Or should
I ask elsewhere ;-), like on hackers (I'm not on that list but can subscribe).
If my assumptions forwarded below are generally correct in regards to
current state of things, then simple "yes" will be enough for me, and I
will keep finding and reading docs.

	thanks!
-- 
--- Artur Pietruk, arturp(at)plukwa(dot)net

On Fri, Dec 17, 2004 at 11:07:42PM +0100, Artur Pietruk wrote:
> 	Hi,
> 
> 	I'm happy user of PostgreSQL for some years. I'm intrested to
> confirm how exactly transaction engine is implemented in current
> PostgreSQL version. I made my own findnings, based on my personal
> experiences through years of using PGSQL, and by reading some pgsql docs
> and presentations made by developers that I've found on web (going
> back as far as to some old writings about postgres on Berkeley Uniwersity).
> 
> 	Here is how I understand it works in general (please note that
> english is not my native language, and in some cases I might not know
> correct english terms to use):
> 
> 	- Transaction isolation is done in smart way via some kind of
> 	  "scratch"/"temporary" buffers, here implemented as tuples with
> 	  versioning - where the valid tuple is the last commited, or
> 	  last written under the current transaction
> 
> 	- Transaction multiprocessing flow consistency is implemented
> 	  via two phased locking, with locks for read and write, where
> 	  multiple reads of tuple by different transactions are allowed
> 	  as long as no single transaction has written; and if different
> 	  transaction try to combine read/write and write on the same
> 	  tuple, then the one who tries to acquire lock later, is
> 	  waiting until lock is released.
> 
> 	And my question is: are the above assumptions on inner workings
> valid for current PGSQL version? Is there anything important about state
> of things, that I'm missing? Are there any good pointers to docs where I
> could read about pgsql internals in regards to transactioning?
> 
> 	Thanks in advance for answer!
> 
> 	PS. And as a long time pgsql user, I need to say big thanks for
> develpers and supporters of postgres! I like and admire the PostgreSQL's
> way of doing things in a clean "the right" way, according to standards,
> keeping in mind future expand of PGSQL features and so on.
> 
> 	Best regards,
> -- 
> --- Artur Pietruk, arturp(at)plukwa(dot)net
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org

In response to

pgsql-admin by date

Next:From: Chris HooverDate: 2004-12-21 00:02:44
Subject: Re: Any tools to compare db's
Previous:From: Tom LaneDate: 2004-12-20 19:01:09
Subject: Re: From latin9 to sql_ascii??

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group