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

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
EnterpriseDB http://www.enterprisedb.com

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