On Friday March 21 2003 10:07, Tom Lane wrote:
> >
> > Well, I'm trying to capture a 64-bit psuedo-transaction ID, just like
> > the WAL record number, but to do it within a C trigger so I can queue
> > it into another table and have all-or-none semantics. Am I correct in
> > assuming the XLogInsert() call is made after the transaction is
> > guaranteed to completed? If so, wouldn't this be beyond the triggered
> > function's reach?
>
> It's certainly out of reach of anything executed within the transaction,
> since by definition the commit record is only written after the
> transaction is done. It seems to me to be a contradiction in terms to
> expect within-transaction actions to have any information about commit
> order of their transaction.
I see your point. Maybe it's not possible to get perfect ordering from any
information available within a transaction?
Using the transaction ID for ordering seems problematic given the
variability of transaction lifetimes, not to mention the 32-bit issue. I
wonder if it'd be advisable to make WAL data available in a (system?)
table, maybe mapping the transaction ID to the WAL record number? Just
looking for some way to make the true commit order visible to a SQL query
in order to leverage existing replication code ...
Ed