From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fast promotion, loose ends |
Date: | 2013-04-24 07:57:16 |
Message-ID: | CA+U5nMJ-VA5G7rnvphWtiAFgnLbnhbAu6dQUc07OFYM8=eqMwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24 April 2013 08:23, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> On 22.04.2013 18:44, Simon Riggs wrote:
>>
>> On 22 April 2013 09:29, Heikki Linnakangas<hlinnakangas(at)vmware(dot)com>
>> wrote:
>>
>>> Hmm. That requires write access to $DATADIR, so that's not quite the same
>>> thing as the trigger_file recovery.conf option.
>>
>>
>> Well, you also (elsewhere) requested that we must keep recovery.conf
>> in $DATADIR, so it needs to be writable.
>
>
> That's a slightly different requirement. $DATADIR must be writable by the
> process that restores the backup or puts the server into standby mode, while
> trigger_file needs to be writable by the process that triggers failover.
> Those are not necessarily the same thing. I'm thinking of a heartbeat
> process that triggers failover by creating a file on an NFS server or
> similar. Possibly the same location where the WAL archive is located.
> $DATADIR would be stored elsewhere.
The default you've requested is fast promotion and I've agreed to that.
The ability to write a file called "promote" to $DATADIR is there as a
protection in case we need it in the field, its not going to be the
primary mechanism any more. So if you're not intending to use it ever,
it doesn't seem worth discussing the fact you don't like its location.
But if you do want to discuss it, I think it's unreasonable of you to
demand recovery.conf cannot be outside $DATADIR and then also demand
related files be relocatable outside $DATADIR as well, the exact
opposite. We had the chance to avoid making $DATADIR writable
externally and that's gone now, at least for now.
Here's the patch I was intending to apply. Please let me know if you
have comments.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
set_fast_promotion_as_default.v1.patch | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-04-24 08:10:26 | Re: Fast promotion, loose ends |
Previous Message | Heikki Linnakangas | 2013-04-24 07:23:32 | Re: Fast promotion, loose ends |