pg.ddx.io pgsql-sql@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Getting current transaction id 3+ messages / 2 participants [nested] [flat]
* Getting current transaction id @ 2002-09-23 16:03 Michael Paesold <mpaesold@gmx.at> 2002-09-25 17:12 ` Re: Getting current transaction id Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 1 reply; 3+ messages in thread From: Michael Paesold @ 2002-09-23 16:03 UTC (permalink / raw) To: pgsql-sql Hi all, I just read it's possible to get the MVCC last version numbers. Is it also possible to get the current transaction id? Would it be possible to check later if that transaction has been commited? This would be nice for a distributed application to enforce an "exactly once" semantics for transactions (even if there are network related errors while the server sends ack for commiting a transaction). And if it's possible, how long would that information be valid, i.e. when do transaction id's get reused? If it's not working I will have to implement my own transactions table. Thanks in advance, Michael Paesold -- Werden Sie mit uns zum "OnlineStar 2002"! Jetzt GMX wählen - und tolle Preise absahnen! http://www.onlinestar.de ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Getting current transaction id 2002-09-23 16:03 Getting current transaction id Michael Paesold <mpaesold@gmx.at> @ 2002-09-25 17:12 ` Tom Lane <tgl@sss.pgh.pa.us> 2002-09-25 20:21 ` Re: Getting current transaction id Michael Paesold <mpaesold@gmx.at> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2002-09-25 17:12 UTC (permalink / raw) To: Michael Paesold <mpaesold@gmx.at>; +Cc: pgsql-sql Michael Paesold <mpaesold@gmx.at> writes: > I just read it's possible to get the MVCC last version numbers. Is it also > possible to get the current transaction id? Well, there's the brute force way: insert a tuple in some table and look at its xmin. Offhand I don't think we provide a SQL function to read current transaction id, though it'd surely be a trivial addition. > Would it be possible to check > later if that transaction has been commited? This would be nice for a distributed > application to enforce an "exactly once" semantics for transactions (even if > there are network related errors while the server sends ack for commiting a > transaction). Again, it's not an exported operation, though you could add a SQL function that called TransactionIdDidCommit(). > And if it's possible, how long would that information be valid, i.e. when do > transaction id's get reused? That would be the tricky part. The ID would be reused after 4 billion transactions, which is long enough that you probably don't care ... but the segment of the transaction log that has the associated commit bit will be recycled as soon as the server has no internal use for it anymore, which could be as early as the next database-wide VACUUM. If you tried to call TransactionIdDidCommit() after that, you'd get the infamous "can't open pg_clog/nnnn" error. > If it's not working I will have to implement my own transactions table. That's what I'd recommend. Transaction IDs are internal to the database and are not designed for users to rely on. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Getting current transaction id 2002-09-23 16:03 Getting current transaction id Michael Paesold <mpaesold@gmx.at> 2002-09-25 17:12 ` Re: Getting current transaction id Tom Lane <tgl@sss.pgh.pa.us> @ 2002-09-25 20:21 ` Michael Paesold <mpaesold@gmx.at> 0 siblings, 0 replies; 3+ messages in thread From: Michael Paesold @ 2002-09-25 20:21 UTC (permalink / raw) To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-sql Tom Lane wrote: > Michael Paesold <mpaesold@gmx.at> writes: [snip] > > If it's not working I will have to implement my own transactions table. > > That's what I'd recommend. Transaction IDs are internal to the database > and are not designed for users to rely on. > > regards, tom lane Well, after reading your explanation I agree with you that it is better to have my own transaction table. I appreciate your detailed response. Thanks very much! Best Regards, Michael Paesold ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2002-09-25 20:21 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2002-09-23 16:03 Getting current transaction id Michael Paesold <mpaesold@gmx.at> 2002-09-25 17:12 ` Tom Lane <tgl@sss.pgh.pa.us> 2002-09-25 20:21 ` Michael Paesold <mpaesold@gmx.at>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox