From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New sync commit mode remote_write |
Date: | 2012-04-19 16:38:48 |
Message-ID: | CAMkU=1xV+HceSR3sgGGrHPjMjEcSvfemNbtMQwCaMasV=D1Zsw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 19, 2012 at 2:47 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Apr 19, 2012, at 5:05 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> I admit to not having followed the discussion around the new mode for
>> synchronous_commit very closely, so my apologies if this has been
>> discussed and dismiseed - I blame failing to find it int he archives
>> ;)
>>
>> My understanding from looking at the docs is that
>> synchronous_commit=remote_write will always imply a *local* commit as
>> well.
>>
>> Is there any way to set the system up to do a write to the remote,
>> ensure it's in memory of the remote (remote_write mode, not full sync
>> to disk), but *not* necessarily to the local disk? Meaning we're ok to
>> release the transaction when the data is in memory both locally and
>> remotely but not wait for I/O?
>
> If we crash, the slave can end up ahead of the master, and then it's hopelessly corrupted...
>
> Maybe we could engineer around this, but it hasn't been done yet.
The work around would be for the master to refuse to automatically
restart after a crash, insisting on a fail-over instead (or a manual
forcing of recovery)?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-04-19 17:04:33 | Re: Bug tracker tool we need |
Previous Message | Dimitri Fontaine | 2012-04-19 15:42:00 | Re: Bug #6593, extensions, and proposed new patch policy |