| 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 18:37:37 |
| Message-ID: | 200303221137.37759.pgsql@bluepolka.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Saturday March 22 2003 11:29, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > Actually, dbmirror does it in a couple of steps, but I think this is
> > the basic idea. So the queued tuple changes are groupable (and thus
> > replayable) by xid and order of queueing. Then the slave gets them in
> > the hopefully-correct order via
> > select ...
> > from queue q
> > where q.xid is in some appropriate range
> > order by xid asc, tuple_id asc;
>
> I think this last part is wrong. It shouldn't be using the xid as part
> of the ordering, only the sequence value.
Why not? How would you replay them on the slave in the same transaction
groupings and order that occurred on the master?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dennis Gearon | 2003-03-22 18:49:41 | Re: configuration according to the database |
| Previous Message | Tom Lane | 2003-03-22 18:29:01 | Re: 32/64-bit transaction IDs? |