On Saturday March 22 2003 8:44, Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.net> writes:
> > create table pg_xlog (
> > xid int4 unique not null,
> > recno int8 unique not null,
> > );
> > -- recno = (XLogRecPtr.xlogid) << 32) + XLogRecPtr.xrecoff
> >
> > This would map transaction IDs to WAL log record numbers. It seems
> > straight-forward to get the right data into this table.
>
> ... except that once a transaction has committed, it can't go around
> making more database entries. You can only modify the DB within a
> transaction.
There may be other good reasons not to do it, but it appears it does not all
need to be done within the trigger:
1. Within the transaction, a user trigger records the transaction ID into a
table along with tuple data via GetCurrentTransactionId() just as dbmirror
and rserv do now, essentially like
insert into replication_queue (xid, data, ...)
2. In xact.c, RecordTransactionCommit() inserts the (xid,recno) pair into
pg_xlog just after XLogInsert() for the commit. It doesn't matter if it's
within reach of the user's transaction-constrained trigger code or not
because it's done by the system.
3. An asyncronous slave replicator comes along later and match the xid to
to the replication tuples, as in
select
from pg_xlog l, replication_queue q
where l.xid = q.xid
order by l.recno;
...and gets a guaranteed ordering.
I'm also wondering if my concerns are unfounded in regard to the impact of
variable transaction lifetimes on the xid. Maybe MVCC maybe takes care of
any concerns from variable transaction lifetimes so that the xid, even
though it comes from the beginning of the transaction, is a reliable
ordering?
Ed
