Horton

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

Marko Kreen <markokr@gmail.com>

View thread
From: Marko Kreen <markokr@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-06-19T20:58:44Z
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 Mon, Jun 18, 2012 at 6:35 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 13 June 2012 19:28, Andres Freund <andres@2ndquadrant.com> wrote:
>> This adds a new configuration parameter multimaster_node_id which determines
>> the id used for wal originating in one cluster.
>
> Looks good and it seems this aspect at least is commitable in this CF.
>
> Design decisions I think we need to review are
>
> * Naming of field. I think origin is the right term, borrowing from Slony.

I have not read too deeply here, so maybe I am missing
some important detail here, but idea that users need
to coordinate a integer config parameter globally does not
sound too attractive to me.

Why not limit integers to local storage only and map
them to string idents on config, UI and transport?

-- 
marko