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

On 20.06.2012 11:17, Simon Riggs wrote:
> On 20 June 2012 15:45, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> 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?
>
> As explained elsewhere, wal_level = logical (or similar) would be used
> to provide any additional logical information required.
>
> Update and Delete WAL records already need to be different in that
> mode, so additional info would be placed there, if there were any.
>
> In the case of reflexive updates you raised, a typical response in
> other DBMS would be to represent the query
> UPDATE SET counter = counter + 1
> by sending just the "+1" part, not the current value of counter, as
> would be the case with the non-reflexive update
> UPDATE SET counter = 1
>
> Handling such things in Postgres would require some subtlety, which
> would not be resolved in first release but is pretty certain not to
> require any changes to the WAL record header as a way of resolving it.
> Having already thought about it, I'd estimate that is a very long
> discussion and not relevant to the OT, but if you wish to have it
> here, I won't stop you.

Yeah, I'd like to hear briefly how you would handle that without any
further changes to the WAL record header.

>>> 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.
>
> As explained, we can do nothing without the origin id. It is not
> optional or avoidable in the way you've described.

It's only needed for multi-master replication, where the same table can
be updated from multiple nodes. Just leave that out for now. There's
plenty of functionality and issues left even without that.

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