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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
Date: 2012-06-20 07:45:56
Message-ID: 4FE17FB4.9010001@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-06-20 07:48:22 Re: pgbench--new transaction type
Previous Message Heikki Linnakangas 2012-06-20 07:32:38 Re: pgbench--new transaction type