Re: PITR potentially broken in 9.2

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: PITR potentially broken in 9.2
Date: 2012-12-05 16:24:21
Message-ID: 20121205162421.GB20456@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2012-12-05 11:11:23 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2012-12-05 13:34:05 +0000, Simon Riggs wrote:
> >> @@ -5883,6 +5889,17 @@ StartupXLOG(void)
> >> } while (record != NULL && recoveryContinue);
> >>
> >> /*
> >> + * We've reached stop point, but not yet applied last
> >> + * record. Pause AFTER final apply, if requested, but
> >> + * only if users can connect to send a resume message
> >> + */
> >> + if (reachedStopPoint && recoveryPauseAtTarget && recoveryApply)
> >> + {
> >> + SetRecoveryPause(true);
> >> + recoveryPausesHere();
> >> + }
> >> +
> >> + /*
>
> > I find the above comment a bit misleading because by now we have in fact
> > applied the last record...
>
> I'd go further than that: a pause after we've exited the loop is
> completely stupid. The only reason for pausing is to let the user
> choose whether to continue applying WAL or not. If you've already
> made that choice, you might as well let the system come up fully.

Yes, that puzzles me as well.

Basically the whole logical arround recoveryApply seems to be broken
currently. Because if recoveryApply=false we currently don't pause at
all because we jump out of the apply loop with the break. I guess thats
what Simon tried to address with the patch. But the new behaviour seems
to be strane as well a

> But I can't make any sense of the rest of this patch, because it seems
> to be randomly rearranging a whole lot of stuff that's unrelated to
> pausing. If you think all these changes are in fact necessary, could
> you break it down a little more?

I think part !recoveryApply changes makes sense, but it needs more...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-12-05 16:40:16 Re: PITR potentially broken in 9.2
Previous Message Tom Lane 2012-12-05 16:11:23 Re: PITR potentially broken in 9.2

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-12-05 16:24:29 Re: autovacuum truncate exclusive lock round two
Previous Message Tom Lane 2012-12-05 16:11:23 Re: PITR potentially broken in 9.2