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

Re: [PATCH] Provide 8-byte transaction IDs to user level

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Provide 8-byte transaction IDs to user level
Date: 2006-07-26 17:35:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality. 
Perhaps pgfoundry would be a better place for this.


Marko Kreen wrote:
> Intro
> -----
> Following patch exports 8 byte txid and snapshot to user level
> allowing its use in regular SQL.  It is based on Slony-I xxid
> module.  It provides special 'snapshot' type for snapshot but
> uses regular int8 for transaction ID's.
> Exported API
> ------------
> Type: snapshot
> Functions:
>   current_txid()			returns int8
>   current_snapshot()			returns snapshot
>   snapshot_xmin(snapshot)		returns int8
>   snapshot_xmax(snapshot)		returns int8
>   snapshot_active_list(snapshot)	returns setof int8
>   snapshot_contains(snapshot, int8)	returns bool
>   pg_sync_txid(int8)			returns int8
> Operation
> ---------
> Extension to 8-byte is done by keeping track of wraparound count
> in pg_control.  On every checkpoint, nextxid is compared to one
> stored in pg_control.  If value is smaller wraparound happened
> and epoch is inreased.
> When long txid or snapshot is requested, pg_control is locked with
> LW_SHARED for retrieving epoch value from it.  The patch does not
> affect core functionality in any other way.
> Backup/restore of txid data
> ---------------------------
> Currently I made pg_dumpall output following statement:
>   "SELECT pg_sync_txid(%d)", current_txid()
> then on target database, pg_sync_txid if it's current
> (epoch + GetTopTransactionId()) are larger than given argument.
> If not then it bumps epoch, until they are, thus guaranteeing that
> new issued txid's are larger then in source database.  If restored
> into same database instance, nothing will happen.
> Advantages of 8-byte txids
> --------------------------
> * Indexes won't break silently.  No need for mandatory periodic
>   truncate which may not happen for various reasons.
> * Allows to keep values from different databases in one table/index.
> * Ability to bring data into different server and continue there.
> Advantages in being in core
> ---------------------------
> * Core code can guarantee that wraparound check happens in 2G transactions.
> * Core code can update pg_control non-transactionally.  Module
>   needs to operate inside user transaction when updating epoch
>   row, which bring various problems (READ COMMITTED vs. SERIALIZABLE,
>   long transactions, locking, etc).
> * Core code has only one place where it needs to update, module
>   needs to have epoch table in each database.
> Todo, tothink
> -------------
> * Flesh out the documentation.  Probably needs some background.
> * Better names for some functions?
> * pg_sync_txid allows use of pg_dump for moveing database,
>   but also adds possibility to shoot in the foot by allowing
>   epoch wraparound to happen.  Is "Don't do it then" enough?
> * Currently txid keeps its own copy of nextxid in pg_control,
>   this makes clear data dependencies.  Its possible to drop it
>   and use ->checkPointCopy->nextXid directly, thus saving 4 bytes.
> * Should the pg_sync_txid() issued by pg_dump instead pg_dumpall?
> -- 
> marko

[ Attachment, skipping... ]

> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

  Bruce Momjian   bruce(at)momjian(dot)us

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Bort, PaulDate: 2006-07-26 18:04:18
Subject: Re: GUC with units, details
Previous:From: Gregory StarkDate: 2006-07-26 17:23:45
Subject: Re: Better name/syntax for "online" index creation

pgsql-patches by date

Next:From: Zdenek KotalaDate: 2006-07-26 19:51:56
Subject: Re: Allow commenting of variables in postgresql.conf to -
Previous:From: Bruce MomjianDate: 2006-07-26 17:15:45
Subject: Re: [HACKERS] Patch for VS.Net 2005's strxfrm() bug

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