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

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

From: Marko Kreen <markokr(at)gmail(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: [PATCH] Provide 8-byte transaction IDs to user level
Date: 2006-07-21 14:17:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches

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


  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


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?



pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-07-21 14:18:46
Subject: Re: Transaction Speed and real time database
Previous:From: Jim C. NasbyDate: 2006-07-21 14:08:32
Subject: Re: [PATCHES] 8.2 features?

pgsql-patches by date

Next:From: Tom LaneDate: 2006-07-21 14:20:25
Subject: Re: BF Failure on Bandicoot
Previous:From: Jim C. NasbyDate: 2006-07-21 14:08:32
Subject: Re: [PATCHES] 8.2 features?

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