From: | Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Should we remove "not fast" promotion at all? |
Date: | 2013-08-09 03:14:57 |
Message-ID: | 52045EB1.6020809@po.ntts.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I understood it's too late to change the feature.
I hope it will be revised in 9.4!
(2013/08/09 4:13), Josh Berkus wrote:
> On 08/08/2013 11:01 AM, Andres Freund wrote:
>
>> I don't think anybody working on related areas of the code thinks it's
>> rock solid.
>> But anyway, I just don't see the downside of allowing problem
>> analysis. You're free to do more testing, review, whatever before the
>> release.
>
> I'm 100% with you that we ought to keep the slow failover code around
> and accessible to debugging. What I'm asking is whether it should still
> be explicitly available to users, and the default. Based on your
> feedback, it's sounding like it should be.
>
In my opinion, the default behavior "fast promote" is ok.
Because we don't have any explicit problem with it for now.
And we shouldn't mention about "normal promote" in document.
I think it will make user confused if do so.
By the way, I'm thinking about when these trigger files(*)
are unlinked.
(*)Now I treat these three files
1) a file specified in trigger_file
2) ${PGDATA}/promote
3) ${PGDATA}/fast_promote
Current source has a problem in some corner cases.
It occurs by the timing of detecting these files.
for example:
------
case1:
createing 1) and executing "pg_ctl promote" occur at the same time.
case2:
creating 1) and promoting at recovery-end(by recovery_target_xxx)
occur at the same time.
------
1) is created, but promoting completes by another trigger.
Both cases 1) remains on the server.
If user doesn't know it and make a standby on the server,
the standby will promote soon.
I think this is not so big problem, but not user-friendly.
Against this, I'm thinking unlinking these files before
starting recovery.
This should be fixed in 9.4 too?
---------
Tomonari Katsumata
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2013-08-09 03:58:42 | Re: 9.4 regression |
Previous Message | Craig Ringer | 2013-08-09 02:57:03 | Re: Proposal for XML Schema Validation |