From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Exposing the Xact commit order to the user |
Date: | 2010-05-28 23:19:54 |
Message-ID: | 201005282319.o4SNJt314194@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck wrote:
> >> Reading the entire WAL just to find all COMMIT records, then go back to
> >> the origin database to get the actual replication log you're looking for
> >> is simpler and more efficient? I don't think so.
> >
> > Agreed, but I think I've not explained myself well enough.
> >
> > I proposed two completely separate ideas; the first one was this:
> >
> > If you must get commit order, get it from WAL on *origin*, using exact
> > same code that current WALSender provides, plus some logic to read
> > through the WAL records and extract commit/aborts. That seems much
> > simpler than the proposal you outlined and as SR shows, its low latency
> > as well since commits write to WAL. No need to generate event ticks
> > either, just use XLogRecPtrs as WALSender already does.
> >
> > I see no problem with integrating that into core, technically or
> > philosophically.
> >
>
> Which means that if I want to allow a consumer of that commit order data
> to go offline for three days or so to replicate the 5 requested, low
> volume tables, the origin needs to hang on to the entire WAL log from
> all 100 other high volume tables?
I suggest writing an external tool that strips out what you need that
can be run at any time, rather than creating a new data format and
overhead for this usecase.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-05-29 01:07:51 | Re: Exposing the Xact commit order to the user |
Previous Message | Bruce Momjian | 2010-05-28 23:16:28 | Re: Clearing psql's input buffer after auto-reconnect |