From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 32/64-bit transaction IDs? |
Date: | 2003-03-22 16:17:24 |
Message-ID: | 200303220917.24954.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Saturday March 22 2003 9:15, Ed L. wrote:
> On Saturday March 22 2003 8:44, Tom Lane wrote:
> > "Ed L." <pgsql(at)bluepolka(dot)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.
>
...
>
> 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.
Am I correct in assuming the system can modify system tables outside a
transaction?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-03-22 16:26:09 | Re: 32/64-bit transaction IDs? |
Previous Message | Ed L. | 2003-03-22 16:15:07 | Re: 32/64-bit transaction IDs? |