Re: Synchronization levels in SR

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jan Wieck <JanWieck(at)yahoo(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronization levels in SR
Date: 2010-06-04 02:57:05
Message-ID: AANLkTin09CcMYjspixEaJm4RlcX9JNG2_330m6mq3h49@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> On 5/27/2010 4:31 PM, Bruce Momjian wrote:
>>
>> Heikki Linnakangas wrote:
>>>
>>> BTW, I think we're going to need a separate config file for listing the
>>> standbys anyway. There you can write per-server rules and options, but
>>> explicitly knowing about all the standbys also allows the master to recycle
>>> WAL as soon as it has been streamed to all the registered standbys.
>>> Currently we just keep wal_keep_segments files around, just in case there's
>>> a standby out there that needs them.
>>
>> Ideally we could set 'slave_sync_count' and 'slave_commit_continue_mode'
>> on the master, and allow the sync/async mode to be set on each slave,
>> e.g. if slave_sync_count = 2 and slave_commit_continue_mode = #2, then
>> two slaves with sync mode of #2 or stricter have to complete before the
>> master can continue.
>>
>> Naming the slaves on the master seems very confusing because I am
>> unclear how we would identify named slaves, and the names have to match,
>> etc.
>> Also, what would be cool would be if you could run a query on the master
>> to view the SR commit mode of each slave.
>
> What would be the use case for such a query?

Monitoring?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-06-04 03:09:12 Re: functional call named notation clashes with SQL feature
Previous Message Robert Haas 2010-06-04 02:55:40 Re: [pgsql-hackers] Daily digest v1.10705 (13 messages)