Horton

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

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Marko Kreen <markokr@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-06-19T21:39:10Z
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 June 2012 04:58, Marko Kreen <markokr@gmail.com> wrote:
> 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?

Yes, that can be done. This is simply how the numbers are used
internally, similar to oids.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services