On Tue, May 13, 2014 at 1:36 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Mon, May 12, 2014 at 8:40 PM, Heikki Linnakangas
>> wrote:
>>> I agree the new behavior is better, and we should just remove the Open Items
>>> entry.
>
>> Yes. I just removed that entry.
>
> Our practice in past years
Fujii Masao writes:
> On Mon, May 12, 2014 at 8:40 PM, Heikki Linnakangas
> wrote:
>> I agree the new behavior is better, and we should just remove the Open Items
>> entry.
> Yes. I just removed that entry.
Our practice in past years has been to move items to a separate "Resolved
Issues" sectio
On Mon, May 12, 2014 at 8:40 PM, Heikki Linnakangas
wrote:
> On 05/12/2014 02:29 PM, Fujii Masao wrote:
>>
>> Hmm.. probably I have the same opinion with you. If I understand this
>> correctly,
>> an immediate shutdown doesn't call CancelBackup() in 9.4 or before. But
>> the
>> commit 82233ce unin
On 05/12/2014 02:29 PM, Fujii Masao wrote:
Hmm.. probably I have the same opinion with you. If I understand this correctly,
an immediate shutdown doesn't call CancelBackup() in 9.4 or before. But the
commit 82233ce unintentionally changed an immediate shutdown so that it calls
CancelBackup().
O
On Mon, May 12, 2014 at 4:52 PM, Heikki Linnakangas
wrote:
> On 05/09/2014 05:19 PM, Fujii Masao wrote:
>>
>> On Thu, Mar 20, 2014 at 11:38 PM, Alvaro Herrera
>> wrote:
>>>
>>> Kyotaro HORIGUCHI escribió:
Hi, I confirmed that 82233ce7ea4 surely did it.
At Wed, 19 Mar 2014 09:3
On 05/09/2014 05:19 PM, Fujii Masao wrote:
On Thu, Mar 20, 2014 at 11:38 PM, Alvaro Herrera
wrote:
Kyotaro HORIGUCHI escribió:
Hi, I confirmed that 82233ce7ea4 surely did it.
At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
Fujii Masao escribió:
On Wed, Mar 19, 2014 at 7:57 PM, Heik
On Thu, Mar 20, 2014 at 11:38 PM, Alvaro Herrera
wrote:
> Kyotaro HORIGUCHI escribió:
>> Hi, I confirmed that 82233ce7ea4 surely did it.
>>
>> At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
>> > Fujii Masao escribió:
>> > > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
>> > > wrot
Hello,
> I don't think we should consider changing long-established behavior in
> the back-branches. The old behavior may not be ideal, but that
> doesn't mean it's a bug.
Ok, I understand that. I give it up.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-h
On Tue, Apr 15, 2014 at 2:52 AM, Kyotaro HORIGUCHI
wrote:
> Hello, thank you for the discussion.
>
> At Tue, 1 Apr 2014 11:41:20 -0400, Robert Haas wrote
>>> I don't find that very radical at all. The backup_label file is
>>> *supposed* to be removed on the master if it crashes during the
>>> bac
Hello, thank you for the discussion.
At Tue, 1 Apr 2014 11:41:20 -0400, Robert Haas wrote
>> I don't find that very radical at all. The backup_label file is
>> *supposed* to be removed on the master if it crashes during the
>> backup; and it should never be removed from the backup itself. At
>>
On Tue, Apr 1, 2014 at 12:39 AM, Jeff Janes wrote:
> On Monday, March 31, 2014, Robert Haas wrote:
>>
>> On Fri, Mar 28, 2014 at 1:06 AM, Kyotaro HORIGUCHI
>> wrote:
>> > Mmm. I don't think it is relevant to this problem. The problem
>> > specific here is 'The database was running until just now
On Monday, March 31, 2014, Robert Haas wrote:
> On Fri, Mar 28, 2014 at 1:06 AM, Kyotaro HORIGUCHI
> > wrote:
> > Mmm. I don't think it is relevant to this problem. The problem
> > specific here is 'The database was running until just now, but
> > shutdown the master (by pacemaker), then restart,
On Fri, Mar 28, 2014 at 1:06 AM, Kyotaro HORIGUCHI
wrote:
> Mmm. I don't think it is relevant to this problem. The problem
> specific here is 'The database was running until just now, but
> shutdown the master (by pacemaker), then restart, won't run
> anymore'. Deleting backup_label after immediat
Hello,
> > At Wed, 19 Mar 2014 19:34:10 +0900, Fujii Masao wrote
> >> > Agreed. Attached patches do that and I could "recover" the
> >> > database state with following steps,
> >>
> >> Adding new option looks like new feature rather than bug fix.
> >> I'm afraid that the backpatch of such a change
Hello,
> > After all, pmState changes to PM_NO_CHILDREN via PM_WAIT_DEAD_END
> > by SIGCHLDs from non-significant processes, then CancelBackup().
>
> Judging from what was being said on the thread, it seems that running
> CancelBackup() after an immediate shutdown is better than not doing it,
> c
On Thu, Mar 20, 2014 at 3:43 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Wed, 19 Mar 2014 19:34:10 +0900, Fujii Masao wrote
>> > Agreed. Attached patches do that and I could "recover" the
>> > database state with following steps,
>>
>> Adding new option looks like new feature rather than bug fix.
Kyotaro HORIGUCHI escribió:
> Hi, I confirmed that 82233ce7ea4 surely did it.
>
> At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
> > Fujii Masao escribió:
> > > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
> > > wrote:
> >
> > > >> 9.4 canceles backup mode even on immediate shut
Hello,
> On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote:
> > The*problematic* operation sequence I saw was performed by
> > pgsql-RA/Pacemaker. It stops a server already with immediate mode
> > and starts the Master as a Standby at first, then
> > promote. Focusing on this situation, there would
Hello,
At Wed, 19 Mar 2014 19:34:10 +0900, Fujii Masao wrote
> > Agreed. Attached patches do that and I could "recover" the
> > database state with following steps,
>
> Adding new option looks like new feature rather than bug fix.
> I'm afraid that the backpatch of such a change to 9.3 or before
Hi, I confirmed that 82233ce7ea4 surely did it.
At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
> Fujii Masao escribió:
> > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
> > wrote:
>
> > >> 9.4 canceles backup mode even on immediate shutdown so the
> > >> operation causes no probl
Fujii Masao escribió:
> On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
> wrote:
> >> 9.4 canceles backup mode even on immediate shutdown so the
> >> operation causes no problem, but 9.3 and before are doesn't.
> >
> > Hmm, I don't think we've changed that behavior in 9.4.
>
> ISTM 82233ce7e
On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
wrote:
> On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote:
>>
>> The*problematic* operation sequence I saw was performed by
>>
>> pgsql-RA/Pacemaker. It stops a server already with immediate mode
>> and starts the Master as a Standby at first, th
On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote:
The*problematic* operation sequence I saw was performed by
pgsql-RA/Pacemaker. It stops a server already with immediate mode
and starts the Master as a Standby at first, then
promote. Focusing on this situation, there would be reasonable to
reset
On Wed, Mar 19, 2014 at 5:28 PM, Kyotaro HORIGUCHI
wrote:
> Hello, thank you for suggestions.
>
> The *problematic* operation sequence I saw was performed by
> pgsql-RA/Pacemaker. It stops a server already with immediate mode
> and starts the Master as a Standby at first, then
> promote. Focusing
Hello, thank you for suggestions.
The *problematic* operation sequence I saw was performed by
pgsql-RA/Pacemaker. It stops a server already with immediate mode
and starts the Master as a Standby at first, then
promote. Focusing on this situation, there would be reasonable to
reset backup positions
On 03/15/2014 05:59 PM, Fujii Masao wrote:
What about adding new option into pg_resetxlog so that we can
reset the pg_control's backup start location? Even after we've
accidentally entered into the situation that you described, we can
exit from that by resetting the backup start location in pg_co
Hello, very sorry to have bothered you by silly question.
me> It is in far better proportion than recovery.conf option:), since
me> it is already warned to be dangerous as its nature. Anyway I'll
me> make sure the situation under the trouble fist.
It looks exactly the 'starting up as standby of e
Thank you for good suggestion.
> > What the mess is once entering this situation, I could find no
> > formal operation to exit from it.
>
> Though this is formal way, you can exit from that situation by
>
> (1) Remove recovery.conf and start the server with crash recovery
> (2) Execute pg_start_
On Fri, Mar 14, 2014 at 7:32 PM, Kyotaro HORIGUCHI
wrote:
> Hello, we found that postgreql won't complete archive recovery
> foever on some situation. This occurs HEAD, 9.3.3, 9.2.7, 9.1.12.
>
> Restarting server with archive recovery fails as following just
> after it was killed with SIGKILL afte
Umm.. Sorry for repeated correction.
2014/03/14 21:12 "Kyotaro HORIGUCHI" :
>
> Ah, ok. I understood what you meant.
> Sorry that I can't confirm rihgt now, the original issue should occur on
the standby.
The original issue should have occurred on standby
> I might've oversimplicated.
>
> regard
Hello,
2014/03/14 20:51 "Heikki Linnakangas" :
> You created recovery.conf in the master server after crash. Just don't do
that.
Ah, ok. I understood what you meant.
Sorry that I can't confirm rihgt now, the original issue should occur on
the standby. I might've oversimplicated.
regards,
--
Kyo
On 03/14/2014 01:24 PM, Kyotaro HORIGUCHI wrote:
Hmm.. What I did is simplly restarting server just after a crash but the
server was accidentially in backup mode. No backup copy is used. Basically,
the server is in the same situation with the simple restart after crash.
You created recovery.co
Sorry, I wrote a little wrong.
2014/03/14 20:24 "Kyotaro HORIGUCHI" :
> I wish to save the database for the case and I suppose it so acceptable.
and I don't suppose it so unacceptable.
regards,
--
Kyotaro Horiguchi
NTT Opensource Software Center
Thank you.
2014/03/14 19:42 "Heikki Linnakangas" :
>
> On 03/14/2014 12:32 PM, Kyotaro HORIGUCHI wrote:
>>
>> Restarting server with archive recovery fails as following just
>> after it was killed with SIGKILL after pg_start_backup and some
>> wal writes but before pg_stop_backup.
>>
>> | FATAL:
On 03/14/2014 12:32 PM, Kyotaro HORIGUCHI wrote:
Restarting server with archive recovery fails as following just
after it was killed with SIGKILL after pg_start_backup and some
wal writes but before pg_stop_backup.
| FATAL: WAL ends before end of online backup
| HINT: Online backup started with
Hello, we found that postgreql won't complete archive recovery
foever on some situation. This occurs HEAD, 9.3.3, 9.2.7, 9.1.12.
Restarting server with archive recovery fails as following just
after it was killed with SIGKILL after pg_start_backup and some
wal writes but before pg_stop_backup.
|
36 matches
Mail list logo
