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 | 4FE18883.1090106@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
(Simon Riggs <simon@2ndQuadrant.com>)
Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On 20.06.2012 11:17, Simon Riggs wrote: > On 20 June 2012 15:45, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Simon RiggsДата:
Сообщение: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node