Horton

Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org, Daniel Farina <daniel@heroku.com>, Simon Riggs <simon@2ndquadrant.com>
Date: 2012-06-19T14:30:59Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't waste the last segment of each 4GB logical log file.

  2. Stamp HEAD as 9.3devel.

  3. Wake WALSender to reduce data loss at failover for async commit.

  4. Make the visibility map crash-safe.

Andres Freund <andres@2ndquadrant.com> writes:
> On Tuesday, June 19, 2012 04:17:01 PM Tom Lane wrote:
>> ...  (If you are thinking
>> of something sufficiently high-level that merging could possibly work,
>> then it's not WAL, and we shouldn't be trying to make the WAL
>> representation cater for it.)

> The idea is that if youre replaying changes on node A originating from node B
> you set the origin to *B* in the wal records that are generated during that. 
> So when B, in a bidirectional setup, replays the changes that A has made it 
> can simply ignore all changes which originated on itself.

This is most certainly not possible at the level of WAL.  As I said
above, we shouldn't be trying to shoehorn high level logical-replication
commands into WAL streams.  No good can come of confusing those concepts.

			regards, tom lane