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

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Daniel Farina <daniel@heroku.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2012-06-20T07:45:56Z
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.

On 20.06.2012 10:32, Simon Riggs wrote:
> On 20 June 2012 14:40, Heikki Linnakangas
>> And I'm worried
>> it might not even be enough in more complicated scenarios.
>
> It is not the only required conflict mechanism, and has never been
> claimed to be so. It is simply one piece of information needed, at
> various times.

So, if the origin id is not sufficient for some conflict resolution 
mechanisms, what extra information do you need for those, and where do 
you put it?

>> Perhaps we need a more generic WAL record annotation system, where a plugin
>> can tack arbitrary information to WAL records. The extra information could
>> be stored in the WAL record after the rmgr payload, similar to how backup
>> blocks are stored. WAL replay could just ignore the annotations, but a
>> replication system could use it to store the origin id or whatever extra
>> information it needs.
>
> Additional information required by logical information will be handled
> by a new wal_level.
>
> The discussion here is about adding origin_node_id *only*, which needs
> to be added on each WAL record.

If that's all we can discuss here is, and all other options are off the 
table, then I'll have to just outright object to this patch. Let's 
implement what we can without the origin id, and revisit this later.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com