Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
От | Heikki Linnakangas |
---|---|
Тема | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |
Дата | |
Msg-id | 4FE17FB4.9010001@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: [PATCH 10/16] Introduce the concept that wal has a
'origin' node
|
Список | 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
В списке pgsql-hackers по дате отправления: