On 2013-06-14 04:56:15 +0900, Fujii Masao wrote:
> On Wed, Jun 12, 2013 at 9:48 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Magnus Hagander (magnus@hagander.net) wrote:
> >> On Wed, Jun 12, 2013 at 1:48 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> > On 2013-06-12 07:53:29 +0900, Fujii Masao wrote:
> >> >> The attached patch fixes this problem. It just changes walsender so that it
> >> >> waits for all the outstanding WAL records to be replicated to the standby
> >> >> before closing the replication connection.
> >> >
> >> > Imo this is a fix that needs to get backpatched... The code tried to do
> >> > this but failed, I don't think it really gives grounds for valid *new*
> >> > concerns.
> >>
> >> +1 (without having looked at the code itself, it's definitely a
> >> behaviour that needs to be fixed)
> >
> > Yea, I was also thinking it would be reasonable to backpatch this; it
> > really looks like a bug that we're allowing this to happen today.
> >
> > So, +1 on a backpatch for me.
>
> +1. I think that we can backpatch to 9.1, 9.2 and 9.3.
I marked the patch as ready for committer.
> In 9.0, the standby doesn't send back any message to the master and
> there is no way to know whether replication has been done up to
> the specified location, so I don't think that we can backpatch.
Agreed. 9.0 doesn't have enough infrastructure for this.
> One note is, even if we backpatch, controlled switchover may require
> the backup in order to follow the timeline switch, in 9.1 and 9.2.
> If we want to avoid the backup in that case, we need to set up
> the shared archive area between the master and the standby and
> set recovery_target_timeline to 'latest'.
Fixing this seems outside the scope of this patch... - and rather
unlikely to be backpatchable.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services