Horton

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

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
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-20T19:13:45Z
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 21:51, Simon Riggs wrote:
> On 21 June 2012 02:32, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> I'm not saying that we need to implement all possible conflict resolution
>> algorithms right now - on the contrary I think conflict resolution belongs
>> outside core
>
> It's a pretty standard requirement to have user defined conflict
> handling, if that's what you mean.
>
> I'm OK with conflict handling being outside of core as a module, if
> that's what people think. We just need a commit hook. That is more
> likely to allow a workable solution with 9.3 as well, ISTM. It's
> likely to be contentious...

Hmm, what do you need to happen at commit time?

We already have RegisterXactCallback(), if that's enough...

>> BTW, one way to work around the lack of origin id in the WAL record header
>> is to just add an origin-id column to the table, indicating the last node
>> that updated the row. That would be a kludge, but I thought I'd mention it..
>
> err, I hope you mean that to be funny. (It wouldn't actually work either)

No, I wasn't serious that we should implement it that way. But now you 
made me curious; why would it not work? If there's an origin-id column 
in a table, it's included in every heap insert/delete/update WAL record. 
Just set it to the current node's id on a local modification, and to the 
origin's id when replaying changes from another node, and you have the 
exact same information as you would with the extra field in WAL record 
header.

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